From owner-svn-src-all@FreeBSD.ORG Wed Aug 27 17:47:16 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34CDE4CC; Wed, 27 Aug 2014 17:47:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08F33337C; Wed, 27 Aug 2014 17:47:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 820A6B960; Wed, 27 Aug 2014 13:47:14 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: svn commit: r270444 - in head/sys: kern sys Date: Wed, 27 Aug 2014 12:29:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201408240904.s7O949sI083660@svn.freebsd.org> <201408261723.10854.jhb@freebsd.org> <20140826215522.GG2737@kib.kiev.ua> In-Reply-To: <20140826215522.GG2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201408271229.19301.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Aug 2014 13:47:14 -0400 (EDT) Cc: Mateusz Guzik , Mateusz Guzik , John-Mark Gurney , src-committers@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 17:47:16 -0000 On Tuesday, August 26, 2014 5:55:22 pm Konstantin Belousov wrote: > On Tue, Aug 26, 2014 at 05:23:10PM -0400, John Baldwin wrote: > > On Tuesday, August 26, 2014 3:32:10 pm John-Mark Gurney wrote: > > > John Baldwin wrote this message on Tue, Aug 26, 2014 at 15:09 -0400: > > > > On Monday, August 25, 2014 6:30:34 pm John-Mark Gurney wrote: > > > > > John Baldwin wrote this message on Mon, Aug 25, 2014 at 13:35 -0400: > > > > > > On Monday, August 25, 2014 07:02:41 PM Mateusz Guzik wrote: > > > > > > > On Mon, Aug 25, 2014 at 10:23:19AM -0400, John Baldwin wrote: > > > > > > > > On Sunday, August 24, 2014 09:04:09 AM Mateusz Guzik wrote: > > > > > > > > > Author: mjg > > > > > > > > > Date: Sun Aug 24 09:04:09 2014 > > > > > > > > > New Revision: 270444 > > > > > > > > > URL: http://svnweb.freebsd.org/changeset/base/270444 > > > > > > > > > > > > > > > > > > Log: > > > > > > > > > Fix getppid for traced processes. > > > > > > > > > > > > > > > > > > Traced processes always have the tracer set as the parent. > > > > > > > > > Utilize proc_realparent to obtain the right process when needed. > > > > > > > > > > > > > > > > Are you sure this won't break things? I know of several applications that > > > > > > > > expect a debugger to be the parent when attached and change behavior as a > > > > > > > > result (e.g. inserting a breakpoint on an assertion failure rather than > > > > > > > > generating a core). > Shouldn't such applications use a breakpoint instruction like INT3 > unconditionally then ? Detection of the attached debugger is inherently > racy, the debugger might have detached after the test. This, and the > fact that default action for the SIGTRAP is coredumping. For whatever reason, the developer may want to not core dump but just log (maybe thrown an exception) normally, but if gdb is attached, it wants to always trigger a breakpoint first (the one I can currently think of is in some uber-fancy assertion handling class). > > Until mjg@'s commit, yes. It's been that way in FreeBSD at least for > > as long as I can remember. Certainly back to 4.x. > > The ps(1) trick continues to work after the commit, since kern_proc > sysctl directly accesses p_pptr to fill ki_ppid. I simply forgot about > it during the review. Ah, well. > Anyway, checking the parent pid is definitely not the right way to > see if the process is under ptrace debugging. What if the parent > is the debugger ? The p_flag AKA ki_flag P_TRACED bit seems to be > the correct indicator. As noted before, that just tells you that something is tracing you, but it might be strace or truss. The evil code above actually looks at p_comm name of the pid and does strstr() "gdb" or the like. -- John Baldwin