From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7912 invoked by alias); 22 Jul 2006 12:31:22 -0000 Received: (qmail 7903 invoked by uid 22791); 22 Jul 2006 12:31:21 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Jul 2006 12:31:19 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6MCV7IH010774; Sat, 22 Jul 2006 08:31:07 -0400 Received: from pobox.stuttgart.redhat.com (pobox.stuttgart.redhat.com [172.16.2.10]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6MCV6i1001333; Sat, 22 Jul 2006 08:31:06 -0400 Received: from lace.redhat.com (vpn50-19.rdu.redhat.com [172.16.50.19]) by pobox.stuttgart.redhat.com (8.12.8/8.12.8) with ESMTP id k6MCV4Jn007160; Sat, 22 Jul 2006 14:31:05 +0200 Received: from lace.redhat.com (localhost.localdomain [127.0.0.1]) by lace.redhat.com (8.13.6/8.13.6) with ESMTP id k6MCV3ZO001995; Sat, 22 Jul 2006 14:31:03 +0200 Received: (from lace@localhost) by lace.redhat.com (8.13.6/8.13.6/Submit) id k6MCV2pB001994; Sat, 22 Jul 2006 14:31:02 +0200 Date: Sat, 22 Jul 2006 12:31:00 -0000 From: Jan Kratochvil To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2) Message-ID: <20060722123102.GA1936@lace.redhat.com> 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="U+BazGySraz5kW0T" Content-Disposition: inline In-Reply-To: <20060721184421.GA22820@nevyn.them.org> User-Agent: Mutt/1.4.2.1i 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/msg00308.txt.bz2 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1107 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. No testsuite case, waiting on MAY_FOLLOW_EXEC resolution below. 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. Regards, Jan --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb-cvs20060722-exec_reset.patch" Content-length: 1102 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182116 exec() causes fatal: Cannot find user-level thread for LWP 4256: generic error Patch below does not enable the new process tracing but it will not crash. MAY_FOLLOW_EXEC enable for GNU/Linux was discouraged by Daniel Jacobowitz. <20060721184421.GA22820@nevyn.them.org> 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 22 Jul 2006 12:17:50 -0000 @@ -875,6 +875,14 @@ 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) + { + 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. */ --U+BazGySraz5kW0T--