This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Fix for gdb crash in "info thread" after exec().
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Date: Tue, 27 May 2008 21:06:15 +0100
- Subject: Re: [RFC] Fix for gdb crash in "info thread" after exec().
- References: <20080527190702.6956D3A6952@localhost>
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