[Bug 201149] devel/gdb: Add fork tracing

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201149

John Baldwin <jhb at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kib at FreeBSD.org

--- Comment #11 from John Baldwin <jhb at FreeBSD.org> ---
(adding kib@ to cc for his insight)

I tracked down the SIGHUP today.  It is not an issue in gdb, and I think it
shouldn't forestall these patches going in to the port.

My test program I had been using did not show the SIGHUP because I had the
parent process wait for the child (I wanted to test that the parent could still
see the child even while being debugged).  Adding a wait() to the parent in
your test was sufficient to avoid the SIGHUP as well.  Looking at the
KTR_PTRACE events, there was a real SIGHUP generated.  I believe what is
happening is that when you follow the child in your test case and use a
breakpoint (or 'catch fork'), then the parent is free to run after the fork and
exits.  GDB runs test programs in a separate process group (via setpgid()
called after vfork() but before execve() of the shell to run a command).  Thus,
when the parent process exits, the kernel considers the associated process
group to be orphaned and calls orphanpg().  If the child process is currently
stopped in ptracestop() when the parent exits, then P_STOPPED() will be true in
orphanpg().  This triggers the SIGHUP/SIGCONT broadcast to the process group
(which only contains the forked child).

I'm not sure what the right fix is here.  Perhaps orphanpg() should ignore
P_STOPPED_TRACE in its check?  You would still get a SIGHUP if another process
in the group was stopped for some other reason which is probably the right
thing, but simply being attached by a debugger wouldn't result in the SIGHUP. 
Thinking some more, I'm not sure P_STOPPED_SINGLE is really right in orphanpg()
either.  If a process in the group happens to be doing execve() when the leader
exits, that shouldn't be grounds for killing the entire group either.  So
perhaps the P_SHOULDSTOP() should just be 'P_SHOULDSTOP(p) == P_STOPPED_SIG'?

-- 
You are receiving this mail because:
You are the assignee for the bug.