Date: Wed, 16 Sep 2015 02:53:09 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 201149] devel/gdb: Add fork tracing Message-ID: <bug-201149-13-coLOvOM4Yd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-201149-13@https.bugs.freebsd.org/bugzilla/> References: <bug-201149-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201149 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #11 from John Baldwin <jhb@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-201149-13-coLOvOM4Yd>