This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit+7.5] [patchv2] Write bpt at the ON_STACK bpt address
- From: Edjunior Barbosa Machado <emachado at linux dot vnet dot ibm dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, Philippe Waroquiers <philippe dot waroquiers at skynet dot be>, Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org, "Maciej W. Rozycki" <macro at codesourcery dot com>, Tom Tromey <tromey at redhat dot com>
- Date: Thu, 02 Aug 2012 23:29:36 -0300
- Subject: Re: [commit+7.5] [patchv2] Write bpt at the ON_STACK bpt address
- References: <5012B1B6.1030003@redhat.com> <1343339398.2258.119.camel@soleil> <20120727184633.GA14182@host2.jankratochvil.net> <20120731073643.GA18696@host2.jankratochvil.net> <501B03E4.1020209@linux.vnet.ibm.com> <m3vch0gacz.fsf@redhat.com> <501B2271.6030406@redhat.com> <m3r4rog316.fsf@redhat.com>
On 08/02/2012 10:47 PM, Sergio Durigan Junior wrote:
> On Thursday, August 02 2012, Pedro Alves wrote:
>
>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>> ../../gdb.git/gdb/frame.c:2396: internal-error: frame_cleanup_after_sniffer: Assertion `frame->prologue_cache == NULL' failed.
>>>> A problem internal to GDB has been detected,
>>>> FAIL: gdb.base/valgrind-infcall.exp: continue (GDB internal error)
>>>> further debugging may prove unreliable.
>>>> Quit this debugging session? (y or n) n
>>>>
>>>> With this error, gdb connection is closed and the testsuite gets stuck
>>>> at this point.
>>>
>>> (Adding Tom to CC list).
>>>
>>> Thanks for the report.
>>>
>>> Just as an FYI (or For Our Information, rather),
>>> http://sourceware.org/ml/gdb-patches/2012-08/msg00075.html clearly fixes
>>> the bug. I will keep an eye on this since I am interested as well.
>>
>> Curious. But is the cause the same? If something sending C-c to gdb at the "wrong" time?
>
> Not sure, but apparently not. I just wanted to make the relation
> between the patch and the problem clear. It is also worth noting that
> the patch fixes only the internal error, but some failures still occur,
> which is something else to be investigated.
>
Indeed, there is still a couple of unexpected failures in gdb.base/valgrind-infcall.exp on ppc64 even with the mentioned patch. One of the failures actually is just the missing `.' prefixing _start() which should be acceptable by the testcase on ppc64 (patch below), but the other seems to be a real problem:
...
continue
Continuing.
==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
--
Edjunior
diff --git a/gdb/testsuite/gdb.base/valgrind-infcall.exp b/gdb/testsuite/gdb.base/valgrind-infcall.exp
index f2aa1ad..df2fb5c 100644
--- a/gdb/testsuite/gdb.base/valgrind-infcall.exp
+++ b/gdb/testsuite/gdb.base/valgrind-infcall.exp
@@ -85,7 +85,7 @@ unset_board_info fileid
clean_restart $executable
-gdb_test "$vgdbcmd" " in _start .*" "target remote for vgdb"
+gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"
gdb_test "monitor v.set gdb_output" "valgrind output will go to gdb.*"