This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [commit+7.5] [patchv2] Write bpt at the ON_STACK bpt address


On Thu, 2012-08-02 at 23:29 -0300, Edjunior Barbosa Machado wrote:
> ==11976== Invalid free() / delete / delete[] / realloc()
> ==11976==    at 0x40458BC: free (vg_replace_malloc.c:427)
> ==11976==    by 0x10000763: main (valgrind-infcall.c:38)
> ==11976==  Address 0x4070040 is 0 bytes inside a block of size 1 free'd
> ==11976==    at 0x40458BC: free (vg_replace_malloc.c:427)
> ==11976==    by 0x10000757: main (valgrind-infcall.c:37)
> ==11976== 
> ==11976== (action on error) vgdb me ...  
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> (gdb) PASS: gdb.base/valgrind-infcall.exp: continue #2
> p gdb_test_infcall ()
> Remote 'g' packet reply is too long: 
> 000000003807eb6800000007ff00d4400000000004068818000000000000000000000007ff00d4b000000007ff00d9f800000007ff00dfb800000000000000000000000000001102000000000000000000000007ff00d4b00000008095169ae0000000002400004200000080950ad5600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000809509fdf800000080950a19f00000000004060940000000000407004000000007ff00d44000000000040700400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000!
> 0000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000040458bc000000000000000024000044000000003807eb680000008095169ae0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000!
> 0000000000
> > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>(gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
> testcase ../../../gdb.git/gdb/testsuite/gdb.base/valgrind-infcall.exp > completed in 1 seconds

Are you sure the above is a ppc64 executable and not a ppc32 executable ?

If that is a ppc32, the problem above might be due to a bug in Valgrind 3.7.0 ppc32 :
some xml files were missing in the install. So, GDB does not get the register description
for the Valgrind ppc32 simulated CPU. This might then cause the above 'packet too long'.
Testing in 64 bits and/or testing with the (not yet released) Valgrind 3.8.0 SVN should
be ok then. 

If this is not the explanation, then some more info might help to understand
what goes wrong (e.g. full log of Valgrind -v -v -v -d -d -d when doing the above test).


Thanks

Philippe



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]