[python] FYI a testcase FAIL: test Frame.read_var_value - error

[python] FYI a testcase FAIL: test Frame.read_var_value - error

[Jan Kratochvil]

Hi,

FYI there is now on [archer-tromey-python] (no merges, just this branch):
FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error


I know nothing more,
Jan

Re: [python] FYI a testcase FAIL: test Frame.read_var_value - error

[Thiago Jung Bauermann]

Hi Jan,

El mar, 03-03-2009 a las 20:47 +0100, Jan Kratochvil escribió:
> FYI there is now on [archer-tromey-python] (no merges, just this branch):
> FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error

Thanks for the heads up. I just tested on ppc-linux, ppc64-linux and
i386-linux but python-frame.exp passes on all of them. Would you mind
sending the excerpt from testsuite/gdb.log for this failure?
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [python] FYI a testcase FAIL: test Frame.read_var_value - error

[Jan Kratochvil]

On Wed, 04 Mar 2009 18:01:59 +0100, Thiago Jung Bauermann wrote:
> El mar, 03-03-2009 a las 20:47 +0100, Jan Kratochvil escribió:
> > FYI there is now on [archer-tromey-python] (no merges, just this branch):
> > FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error
> 
> Thanks for the heads up. I just tested on ppc-linux, ppc64-linux and
> i386-linux but python-frame.exp passes on all of them.

As suggested by Tom could you please try to get x86_64 access on the GCC farm?
	http://gcc.gnu.org/wiki/CompileFarm

> Would you mind sending the excerpt from testsuite/gdb.log for this failure?

python print 'result =', f0.read_var ('b')
result = {i = {0, 1068498944}, d = 0.0625}
(gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error


Regards,
Jan

Re: [python] FYI a testcase FAIL: test Frame.read_var_value - error

[Thiago Jung Bauermann]

El jue, 05-03-2009 a las 23:58 +0100, Jan Kratochvil escribió:
> On Wed, 04 Mar 2009 18:01:59 +0100, Thiago Jung Bauermann wrote:
> > El mar, 03-03-2009 a las 20:47 +0100, Jan Kratochvil escribió:
> > > FYI there is now on [archer-tromey-python] (no merges, just this branch):
> > > FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error
> > 
> > Thanks for the heads up. I just tested on ppc-linux, ppc64-linux and
> > i386-linux but python-frame.exp passes on all of them.
> 
> As suggested by Tom could you please try to get x86_64 access on the GCC farm?
> 	http://gcc.gnu.org/wiki/CompileFarm

I have a personal x86_64 box running Debian unstable and I still don't
see the failure there. Do you see this in x86_64 machines in the compile
farm? If so, I can try to get access there to analyse the problem.

> > Would you mind sending the excerpt from testsuite/gdb.log for this failure?
> 
> python print 'result =', f0.read_var ('b')
> result = {i = {0, 1068498944}, d = 0.0625}
> (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error

This is weird. python-frame.c doesn't have a b variable in f2, which is
where the testcase stops for the tests. It does have an argument named b
in f1, but it surely doesn't have such type. It's a plain int.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

[python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error

[Jan Kratochvil]

On Fri, 06 Mar 2009 04:35:18 +0100, Thiago Jung Bauermann wrote:
> El jue, 05-03-2009 a las 23:58 +0100, Jan Kratochvil escribió:
> > python print 'result =', f0.read_var ('b')
> > result = {i = {0, 1068498944}, d = 0.0625}
> > (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error
> 
> This is weird. python-frame.c doesn't have a b variable in f2, which is
> where the testcase stops for the tests. It does have an argument named b
> in f1, but it surely doesn't have such type. It's a plain int.

I could have investigated it more first (and curious you do not have
glibc-debuginfo installed):

(gdb) info addr b
Symbol "b" is static storage at address 0x33f124d198.
(gdb) info sym 0x33f124d198
inv16 in section .rodata of /lib64/libm.so.6
[`inv16' is just shared common rodata with `b']

IMO GDB should be strictly following the c++ lookup scopes.  This `b' lookup
would therefore require to type `s_atan.c:b' or `atnat.h:b' when some current
frame or current_source_symtab are in a different file.

OK to checkin the patch below?

glibc-20081031T2102/sysdeps/ieee754/dbl-64/atnat.h:113:
  static const number
/**/ b              = {{0x00000000, 0x3fb00000} }, /*  1/16         */

  Compilation Unit @ offset 0x8ac8:
   Length:        0x7cb (32-bit)
   Version:       2
   Abbrev Offset: 10308
   Pointer Size:  8
 <0><8ad3>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <8ad4>   DW_AT_producer    : (indirect string, offset: 0x12e): GNU C 4.3.2 20081105 (Red Hat 4.3.2-7)
    <8ad8>   DW_AT_language    : 1      (ANSI C)
    <8ad9>   DW_AT_name        : (indirect string, offset: 0x13b2): ../sysdeps/ieee754/dbl-64/s_atan.c
    <8add>   DW_AT_comp_dir    : (indirect string, offset: 0x5a7): /usr/src/debug/glibc-20081113T2206/math
    <8ae1>   DW_AT_low_pc      : 0x15ee0
    <8ae9>   DW_AT_high_pc     : 0x18725
    <8af1>   DW_AT_stmt_list   : 0x36a2
 <1><90c2>: Abbrev Number: 15 (DW_TAG_variable)
    <90c3>   DW_AT_name        : b
    <90c5>   DW_AT_decl_file   : 4
    <90c6>   DW_AT_decl_line   : 113
    <90c7>   DW_AT_type        : <0x8f0d>
    <90cb>   DW_AT_location    : 9 byte block: 3 98 d1 4 0 0 0 0 0      (DW_OP_addr: 4d198)

Symbol table '.symtab' contains 1761 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
   302: 000000000004d198     8 OBJECT  LOCAL  DEFAULT   15 b


Regards,
Jan

	Fix false FAIL with libm.so debuginfo installed.
	* gdb.python/python-frame.exp (test Frame.read_var - error): Convert it
	to gdb_test_multiple with XFAIL on the libm instance on `b'.

diff --git a/gdb/testsuite/gdb.python/python-frame.exp b/gdb/testsuite/gdb.python/python-frame.exp
index 083fa90..e9e063a 100644
--- a/gdb/testsuite/gdb.python/python-frame.exp
+++ b/gdb/testsuite/gdb.python/python-frame.exp
@@ -81,9 +81,20 @@ gdb_test "python print 'result =', f0.pc ()" " = \[0-9\]+" "test Frame.pc"
 gdb_test "python print 'result =', f0.addr_in_block ()" " = \[0-9\]+" "test Frame.addr_in_block"
 gdb_test "python print 'result =', f0.older ().equals (f1)" " = True" "test Frame.older"
 gdb_test "python print 'result =', f1.newer ().equals (f0)" " = True" "test Frame.newer"
-gdb_test "python print 'result =', f0.read_var ('b')" \
-  "ValueError: variable 'b' not found.*Error while executing Python code." \
-  "test Frame.read_var - error"
+
+set test "test Frame.read_var - error"
+gdb_test_multiple "python print 'result =', f0.read_var ('b')" $test {
+    -re "ValueError: variable 'b' not found.*Error while executing Python code.\r\n$gdb_prompt $" {
+	pass $test
+    }
+    -re "result = \\\{i = \\\{0, \[0-9\]+\\\}, d = 0\\.\[0-9\]+\\\}\r\n$gdb_prompt $" {
+	# libm.so debuginfo contains file static symbol `b' from `atnat.h'.
+	# local `b' would be find first if it would exist so it is more a PASS.
+	setup_xfail *-*-*
+	fail $test
+    }
+}
+
 gdb_test "python print 'result =', f0.read_var ('a')" " = 1" "test Frame.read_var - success"
 
 gdb_test "python print 'result =', gdb.newest_frame ().equals (f0)" " = True" "test gdb.newest_frame"

Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error

[Thiago Jung Bauermann]

El vie, 06-03-2009 a las 14:25 +0100, Jan Kratochvil escribió:
> On Fri, 06 Mar 2009 04:35:18 +0100, Thiago Jung Bauermann wrote:
> > El jue, 05-03-2009 a las 23:58 +0100, Jan Kratochvil escribió:
> > > python print 'result =', f0.read_var ('b')
> > > result = {i = {0, 1068498944}, d = 0.0625}
> > > (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error
> > 
> > This is weird. python-frame.c doesn't have a b variable in f2, which is
> > where the testcase stops for the tests. It does have an argument named b
> > in f1, but it surely doesn't have such type. It's a plain int.
> 
> I could have investigated it more first (and curious you do not have
> glibc-debuginfo installed):

I actually do have it, but Debian's debuginfo for libc is minimal,
unfortunately.

> OK to checkin the patch below?

Fine by me. Thanks for working on this.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error

[Thiago Jung Bauermann]

El vie, 06-03-2009 a las 11:21 -0300, Thiago Jung Bauermann escribió:
> El vie, 06-03-2009 a las 14:25 +0100, Jan Kratochvil escribió:
> > OK to checkin the patch below?
> 
> Fine by me. Thanks for working on this.

Actually, I think it's better to change the variable name from 'b' to
something hwich will surely not exist anywhere else. What do you think?
I can make that change.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error

[Jan Kratochvil]

On Fri, 06 Mar 2009 15:28:10 +0100, Thiago Jung Bauermann wrote:
> Actually, I think it's better to change the variable name from 'b' to
> something hwich will surely not exist anywhere else. What do you think?
> I can make that change.

Good idea but already checked-in.  Patch it a way you like.

Also XFAIL was probably not right as the system environment was correct.
KFAIL also would not be right as GDB behaves as expected.
Maybe it should have been just PASS as it comes from GDB breakage by design.


Regards,
Jan

Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error

[Thiago Jung Bauermann]

El vie, 06-03-2009 a las 15:31 +0100, Jan Kratochvil escribió:
> On Fri, 06 Mar 2009 15:28:10 +0100, Thiago Jung Bauermann wrote:
> > Actually, I think it's better to change the variable name from 'b' to
> > something hwich will surely not exist anywhere else. What do you think?
> > I can make that change.
> 
> Good idea but already checked-in.  Patch it a way you like.

Ok, I reversed your patch and committed the patch below.
I'm just worried about my lack of sense of humor when choosing the
variable name...

> Also XFAIL was probably not right as the system environment was correct.
> KFAIL also would not be right as GDB behaves as expected.
> Maybe it should have been just PASS as it comes from GDB breakage by design.

PASS wouldn't be good either because if read_var finds a variable the
test doesn't exercise the error path I want it to, so the PASS doesn't
mean anything.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


commit 7479ac4e385bcaa2846c3aad5c616f571ff53c97
Author: Thiago Jung Bauermann <bauerman@br.ibm.com>
Date:   Fri Mar 6 11:49:59 2009 -0300

    Fix python-frame.exp testcase when you have libm.so debuginfo.
    
    Revert "Fix false FAIL with libm.so debuginfo installed."
    This reverts commit eff2403b365bdda84c08eb68890152ca1a58f1c6.
    
	* gdb.python/python-frame.exp (test Frame.read_var - error): Use
	variable name which surely won't exist anywhere.

diff --git a/gdb/testsuite/gdb.python/python-frame.exp b/gdb/testsuite/gdb.python/python-frame.exp
index e9e063a..674c25e 100644
--- a/gdb/testsuite/gdb.python/python-frame.exp
+++ b/gdb/testsuite/gdb.python/python-frame.exp
@@ -81,20 +81,9 @@ gdb_test "python print 'result =', f0.pc ()" " = \[0-9\]+" "test Frame.pc"
 gdb_test "python print 'result =', f0.addr_in_block ()" " = \[0-9\]+" "test Frame.addr_in_block"
 gdb_test "python print 'result =', f0.older ().equals (f1)" " = True" "test Frame.older"
 gdb_test "python print 'result =', f1.newer ().equals (f0)" " = True" "test Frame.newer"
-
-set test "test Frame.read_var - error"
-gdb_test_multiple "python print 'result =', f0.read_var ('b')" $test {
-    -re "ValueError: variable 'b' not found.*Error while executing Python code.\r\n$gdb_prompt $" {
-	pass $test
-    }
-    -re "result = \\\{i = \\\{0, \[0-9\]+\\\}, d = 0\\.\[0-9\]+\\\}\r\n$gdb_prompt $" {
-	# libm.so debuginfo contains file static symbol `b' from `atnat.h'.
-	# local `b' would be find first if it would exist so it is more a PASS.
-	setup_xfail *-*-*
-	fail $test
-    }
-}
-
+gdb_test "python print 'result =', f0.read_var ('variable_which_surely_doesnt_exist')" \
+  "ValueError: variable 'variable_which_surely_doesnt_exist' not found.*Error while executing Python code." \
+  "test Frame.read_var - error"
 gdb_test "python print 'result =', f0.read_var ('a')" " = 1" "test Frame.read_var - success"
 
 gdb_test "python print 'result =', gdb.newest_frame ().equals (f0)" " = True" "test gdb.newest_frame"

Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> IMO GDB should be strictly following the c++ lookup scopes.  This
Jan> `b' lookup would therefore require to type `s_atan.c:b' or
Jan> `atnat.h:b' when some current frame or current_source_symtab are
Jan> in a different file.

I tend to agree.  I think the current behavior is nice with small
programs, but gets unwieldy with larger ones, or when you have
debuginfo for the system libraries.  Also, the delayed symfile hack
would work better with this style of lookup.

Maybe we can try this out at some point.  I suspect we might find it
inconvenient in some situations.

Tom