This is the mail archive of the
mailing list for the GDB project.
[patch] Fix threads vs. fork following
On Mon, Mar 22, 2004 at 12:12:18PM -0500, Daniel Jacobowitz wrote:
> On Thu, Mar 11, 2004 at 01:08:40AM +0000, Michael Snyder wrote:
> > Hey Daniel,
> > Got a question concerning the code in
> > linux-nat.c::linux_handle_extended_wait.
> > You've got a PTRACE_EVENT_FORK event, and now you're going to call
> > waitpid. You pull a pid out of a list of stopped pids, and wait for
> > it using waitpid. In your comment, you explain that you don't have to
> > worry about the pid being a clone, because you didn't ask for pids in
> > the event mask.
> > But how is this affected by threads, especially NPTL threads?
> > I've got a fairly simple test-case (modified from pthreads.c,
> > I'll attach it), in which a child thread calls fork -- but gdb
> > apparently tries to wait on the main thread (or perhaps the most
> > recent event thread). Since that's not the thread that called
> > fork, waitpid returns -1 with "no child". Gdb reports:
> > waiting for new child: No child processes.
> > FWIW, I've tried this on both a single-processor and an SMP machine.
Here's what happened: I was using ptid_get_pid, which gave me the
_process_ ID rather than the _lwp_ ID. I've committed this fix for
HEAD. Should I fix this on the 6.1 branch also?
MontaVista Software Debian GNU/Linux Developer
2004-03-22 Daniel Jacobowitz <firstname.lastname@example.org>
* lin-lwp.c (lin_lwp_wait): Pass the LWP ID to
RCS file: /cvs/src/src/gdb/lin-lwp.c,v
retrieving revision 1.52
diff -u -p -r1.52 lin-lwp.c
--- lin-lwp.c 8 Oct 2003 20:05:56 -0000 1.52
+++ lin-lwp.c 22 Mar 2004 20:02:30 -0000
@@ -1591,8 +1591,7 @@ retry:
/* Handle GNU/Linux's extended waitstatus for trace events. */
if (WIFSTOPPED (status) && WSTOPSIG (status) == SIGTRAP && status >> 16 != 0)
- linux_handle_extended_wait (ptid_get_pid (trap_ptid),
- status, ourstatus);
+ linux_handle_extended_wait (GET_LWP (lp->ptid), status, ourstatus);