From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29180 invoked by alias); 20 Jan 2006 14:35:11 -0000 Received: (qmail 29162 invoked by uid 22791); 20 Jan 2006 14:35:10 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 20 Jan 2006 14:35:09 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EzxM3-0000p0-2c; Fri, 20 Jan 2006 09:35:07 -0500 Date: Fri, 20 Jan 2006 14:35:00 -0000 From: Daniel Jacobowitz To: Girish Shilamkar Cc: gdb-patches@sources.redhat.com Subject: Re: [Patch] Mark the thread_event breakpoint as "not inserted" before calling thread_mourn_inferior Message-ID: <20060120143507.GA2794@nevyn.them.org> Mail-Followup-To: Girish Shilamkar , gdb-patches@sources.redhat.com References: <1137512294.3217.29.camel@krypton> <20060117154004.GA3672@nevyn.them.org> <1137575670.3221.17.camel@krypton> <20060118135735.GA3154@nevyn.them.org> <1137766638.3225.40.camel@krypton> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1137766638.3225.40.camel@krypton> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00247.txt.bz2 On Fri, Jan 20, 2006 at 07:47:18PM +0530, Girish Shilamkar wrote: > > As I suspected something is wrong with your host system, kernel, > > environment, or similar. You may want to try a few others. > Thanks for the reply. I tried gdb-6.4 on Fedora Core 3 & 4 and always > saw that problem. I further tried gdb-6.3 on the same m/c with same > configuration (only the gdb had changed )on which I had seen this > problem and it worked fine. > Then while investigating further about the different behaviour of the > two gdb's i.e. gdb-6.3 and gdb-6.4 I found one difference that gdb-6.3 > doesn't have a function called thread_db_xfer_partial. > > The following call trace is same for both the gdbs You left out the interesting part of the trace; why is it fetching registers? My GDB doesn't. Presumably this is something specific to Red Hat's libthread_db. Does td_thr_validate_p return TD_OK for a thread which is actually dead? > #14 0x081305e0 in memory_remove_breakpoint (addr=4626416, > contents_cache=0x95a7618 "U") at ../../src/gdb/mem- > break.c:91 > #15 0x080cffdd in remove_breakpoint (b=0x95a7600, is=mark_inserted) > at ../../src/gdb/breakpoint.c:1452 > #16 0x080d82aa in delete_breakpoint (bpt=0x95a7558) > at ../../src/gdb/breakpoint.c:6772 > #17 0x080d4258 in remove_thread_event_breakpoints () > at ../../src/gdb/breakpoint.c:4295 > #18 0x08096875 in thread_db_mourn_inferior () > at ../../src/gdb/linux-thread-db.c:1107 This suggests where the problem really ought to be fixed. No point removing breakpoints after the inferior is dead. generic_mourn_inferior arranges to mark all breakpoints as uninserted. Try moving remove_thread_event_breakpoints below the call to target_beneath->to_mourn_inferior (). -- Daniel Jacobowitz CodeSourcery