This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [patch] Fix cleanup in finish_command
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 20 Jun 2013 15:26:56 +0000
- Subject: RE: [patch] Fix cleanup in finish_command
- References: <20130619211444 dot GA29379 at host2 dot jankratochvil dot net> <20130620143118 dot GA11929 at host2 dot jankratochvil dot net> <20130620151806 dot GD4724 at adacore dot com>
> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com]
> Sent: Thursday, June 20, 2013 5:18 PM
> > BTW I have found the crash happens even with this patch, I haven't found the
> > real cause yet.
>
> Interesting, as I couldn't understand the relationship between
> the backtrace and the patch... You might also be in a situation
> similar to what I faced on Darwin: a correct cleanup fix triggering
> a latent bug; In that situation I found it useful to first git-bisect
> to narrow down the commit that caused the change of behavior, and
> then finish the bug off with valgrind's help.
The bisect will point somewhere into my patch series but it won't be
of much help since most of the patches are just preparing for the
enabling patch at the end of the series.
I have not seen those core files.
Can you point me to a specific test where this happens?
Is there some indication in gdb.log?
Are you using remote or native configuration?
Thanks,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052