From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18890 invoked by alias); 24 Jul 2006 19:03:38 -0000 Received: (qmail 18835 invoked by uid 22791); 24 Jul 2006 19:03:36 -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; Mon, 24 Jul 2006 19:03:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G55iG-0003cE-AL; Mon, 24 Jul 2006 15:03:32 -0400 Date: Mon, 24 Jul 2006 19:03:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2) Message-ID: <20060724190332.GA13612@nevyn.them.org> Mail-Followup-To: Jan Kratochvil , gdb-patches@sourceware.org References: <20060614105510.GA12067@host0.dyn.jankratochvil.net> <20060614142552.GA15021@nevyn.them.org> <20060615203519.GA9603@host0.dyn.jankratochvil.net> <20060721181556.GA9150@lace.redhat.com> <20060721184421.GA22820@nevyn.them.org> <20060722123102.GA1936@lace.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060722123102.GA1936@lace.redhat.com> User-Agent: Mutt/1.5.11+cvs20060403 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-07/txt/msg00338.txt.bz2 On Sat, Jul 22, 2006 at 02:31:02PM +0200, Jan Kratochvil wrote: > Hi Daniel, > > please commit if appropriate: > > Created the attached minimal patch fixing the gdb lockup. > > 2006-07-22 Jan Kratochvil > > * linux-thread-db.c (thread_db_wait): Avoid locking up on stale > threading state after TARGET_WAITKIND_EXECD. Thanks. I've committed the attached version; I played around with it a little bit, and discovered that you couldn't re-run unless you remember to remove the thread breakpoints too. > On Fri, 21 Jul 2006 20:44:21 +0200, Daniel Jacobowitz wrote: > ... > > Turning on MAY_FOLLOW_EXEC is not a good idea. No one really knows how > > that behavior works, a lot of it doesn't, and the way it implicitly > > changes the symbol file is very disorienting. Please don't mix it up > > with the fix for your current bug. > > Still I am for MAY_FOLLOW_EXEC as it improves the user experience and makes > debugging of exec()ing processes much more convenient - without having to find > out how each child gets executed and replay such conditions by hand. > > As gdb-6.5 has been released and the MAY_FOLLOW_EXEC feature IMO generally > works for GNU/Linux - isn't appropriate to enable it and settle it down? > I would even like to fix any issues possibly roaring its head. Does anyone else have an opinion on this? I'm starting to think you're right - we should turn it on, invite people to use it, and see what happens. The reason I find it so disorienting is this: % gdb file1 (gdb) run [starts file1] [file1 execs file2] [file2 exits] (gdb) run [file2 starts instead of file1!] I don't know if it should do that or not. I tend to use "run" a lot and want to get back to the beginning of my debug session. -- Daniel Jacobowitz CodeSourcery 2006-07-24 Jan Kratochvil Daniel Jacobowitz * linux-thread-db.c (thread_db_wait): Remove libthread_db after exec events. Index: linux-thread-db.c =================================================================== RCS file: /cvs/src/src/gdb/linux-thread-db.c,v retrieving revision 1.17 diff -u -p -r1.17 linux-thread-db.c --- linux-thread-db.c 18 Jul 2006 22:53:20 -0000 1.17 +++ linux-thread-db.c 24 Jul 2006 18:56:24 -0000 @@ -875,6 +875,15 @@ thread_db_wait (ptid_t ptid, struct targ if (ourstatus->kind == TARGET_WAITKIND_EXITED) return pid_to_ptid (-1); + if (ourstatus->kind == TARGET_WAITKIND_EXECD) + { + remove_thread_event_breakpoints (); + unpush_target (&thread_db_ops); + using_thread_db = 0; + + return pid_to_ptid (GET_PID (ptid)); + } + if (ourstatus->kind == TARGET_WAITKIND_STOPPED && ourstatus->value.sig == TARGET_SIGNAL_TRAP) /* Check for a thread event. */