From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17536 invoked by alias); 27 May 2008 20:06:46 -0000 Received: (qmail 17527 invoked by uid 22791); 27 May 2008 20:06:44 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 May 2008 20:06:19 +0000 Received: (qmail 3342 invoked from network); 27 May 2008 20:06:17 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 May 2008 20:06:17 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] Fix for gdb crash in "info thread" after exec(). Date: Wed, 28 May 2008 15:27:00 -0000 User-Agent: KMail/1.9.9 Cc: Paul Pluzhnikov References: <20080527190702.6956D3A6952@localhost> In-Reply-To: <20080527190702.6956D3A6952@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805272106.16082.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00723.txt.bz2 A Tuesday 27 May 2008 20:07:02, Paul Pluzhnikov wrote: > Ping. > > http://sourceware.org/ml/gdb-patches/2008-05/msg00386.html > > Also re-sending the patch as inline plain-text. > I agree that the threads should not survive across an exec, but the crash you're reporting suggests that something is trimming the ptid when it shouldn't, and that ptid is getting into the thread list. Here's a patch that handles this a bit more generically: http://sourceware.org/ml/gdb-patches/2008-05/msg00230.html In your test case, what is probably happening, is that linux-nat.c/linux-thread-db.c is escaping an event ptid which isn't in the thread list, which doesn't have a ptid.lwp member set, so you're hitting this in handle_inferior_event: /* If it's a new process, add it to the thread database */ ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid) && !ptid_equal (ecs->ptid, minus_one_ptid) && !in_thread_list (ecs->ptid)); if (ecs->ws.kind != TARGET_WAITKIND_EXITED && ecs->ws.kind != TARGET_WAITKIND_SIGNALLED && ecs->new_thread_event) add_thread (ecs->ptid); Which I've been claiming is bad... Could you confirm that this hunk of my patch, Index: src/gdb/linux-thread-db.c =================================================================== --- src.orig/gdb/linux-thread-db.c 2008-05-06 12:22:31.000000000 +0100 +++ src/gdb/linux-thread-db.c 2008-05-06 12:53:18.000000000 +0100 @@ -840,7 +840,7 @@ thread_db_wait (ptid_t ptid, struct targ unpush_target (&thread_db_ops); using_thread_db = 0; - return pid_to_ptid (GET_PID (ptid)); + return ptid; } /* If we do not know about the main thread yet, this would be a good time to ... fixes the issue, and that you were hitting that new_thread_event piece in infrun.c:handle_inferior_event while handling a TARGET_WAITKIND_EXECD ? We may need some more interface cleanup to clear the current thread list across an exec, if the original process had threads, but I don't think your call is in the right place. -- Pedro Alves