From owner-freebsd-ports-bugs@freebsd.org Wed Sep 16 02:53:10 2015 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ECA59CE1A3 for ; Wed, 16 Sep 2015 02:53:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7149C1569 for ; Wed, 16 Sep 2015 02:53:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8G2rAvS089504 for ; Wed, 16 Sep 2015 02:53:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 201149] devel/gdb: Add fork tracing Date: Wed, 16 Sep 2015 02:53:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 02:53:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201149 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #11 from John Baldwin --- (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.