From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 29 23:00:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC584106566C for ; Thu, 29 Apr 2010 23:00:27 +0000 (UTC) (envelope-from tomtinn@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA038FC17 for ; Thu, 29 Apr 2010 23:00:27 +0000 (UTC) Received: by wyb36 with SMTP id 36so742447wyb.13 for ; Thu, 29 Apr 2010 16:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jDDFRnDN8B3+baGo3AECXvvO33XFAv5bbjzjynkgl0k=; b=pjLIppFbmGD4m2Zm7rVWDu61tevVWcmdbJicrZYgWw5uXhYqkgnbLkTIWnyXZnPKsV DzPypqzao06+KTOi2FWX9ufPIfZFfqkR8ySRAXOUcceN3rDmtdA+Md1PIijzBwm+m7ir AFgEWhZCw42sLp3gRpNgz41TBVwoKpoultFMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=TxZ3Y7cLTFs0CnlMwcYEtTBznZscipV8NYOqeYH/v+8TMSj7pHh1IrRBvGEeTIlzWm leZSSCXQSfmDGuDMKcaiQ8MLdFJw8YSPBelFyXZ7fA3tj9UX8CVlUy6qGUbRh2iB8VIU h3I8wO0JX3RoD7TF1Rq+Zy7bF7J7fPQMWK9dI= MIME-Version: 1.0 Received: by 10.216.186.10 with SMTP id v10mr2254294wem.111.1272582017461; Thu, 29 Apr 2010 16:00:17 -0700 (PDT) Received: by 10.216.166.16 with HTTP; Thu, 29 Apr 2010 16:00:16 -0700 (PDT) In-Reply-To: <9EF83DA6-B2D3-456E-B0AF-0B4F5F458A1F@gid.co.uk> References: <9EF83DA6-B2D3-456E-B0AF-0B4F5F458A1F@gid.co.uk> Date: Thu, 29 Apr 2010 23:00:16 +0000 Message-ID: From: Gunnar Hinriksson To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Ptrace segfault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 23:00:27 -0000 2010/4/29 Bob Bishop : > Hi, > > On 29 Apr 2010, at 22:37, Garrett Cooper wrote: > >> On Thu, Apr 29, 2010 at 12:06 PM, Gunnar Hinriksson = wrote: >>> Hello >>> >>> Im having a little problem using ptrace on my system. >>> If I use ptrace to attach to another process the child process >>> segfaults once I detach. >>> For example using this simple program. >>> >>> #include >>> #include >>> #include >>> #include >>> #include >>> >>> int main(int argc, char *argv[]) >>> { >>> =A0 =A0 =A0 =A0int pid =3D atoi(argv[1]); >>> =A0 =A0 =A0 =A0ptrace(PT_ATTACH, pid, 0, 0); >>> =A0 =A0 =A0 =A0wait(NULL); >>> =A0 =A0 =A0 =A0ptrace(PT_DETACH, pid, 0, 0); >>> =A0 =A0 =A0 =A0return 0; >>> } >>> >>> Am I using ptrace incorrectly or is there perhaps a bug in ptrace that >>> causes the child to always segfault ? >> >> =A0 =A0Nope -- it's a bug in your code. From ptrace(2): >> >> =A0 =A0 PT_CONTINUE =A0 The traced process continues execution. =A0The a= ddr argument >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is an address specifying the place w= here execution is to be >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 resumed (a new value for the program= counter), or >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (caddr_t)1 to indicate that executio= n is to pick up where >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it left off. =A0The data argument pr= ovides a signal number to >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 be delivered to the traced process a= s it resumes execution, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 or 0 if no signal is to be sent. >> >> [...] >> >> =A0 =A0 PT_DETACH =A0 =A0 This request is like PT_CONTINUE, except that = it does not > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 allow specifying an alternate place = to continue execution, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and after it succeeds, the traced pr= ocess is no longer >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 traced and continues execution norma= lly. >> >> =A0 =A0Note very carefully the fact that PT_DETACH is like PT_CONTINUE, >> and that PT_CONTINUE says that addr references the memory where the >> execution is going to be resumed. > > Looks to me like a bug in ptrace(PT_DETACH,...) which to agree with ptrac= e(2) ought either to > (a) fail (EINVAL?) if addr !=3D (caddr_t)1, or > (b) ignore addr entirely; it's not clear which. > > OP inferred (b) which is reasonable. > >> HTH, >> -Garrett >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >> >> > > > -- > Bob Bishop =A0 =A0 =A0 =A0 =A0+44 (0)118 940 1243 > rb@gid.co.uk =A0 =A0fax +44 (0)118 940 1295 > =A0 =A0 =A0 =A0 =A0 =A0 mobile +44 (0)783 626 4518 > > > > > > Hello I didn't want to make the code to big so I omitted any tests. About wait(), you are supposed to use wait to check if the child process has stopped successfully. I guess the correct usage would be something like this if im understanding the documentation correctly. if ( wait(WIFSTOPPED(SIGSTOP)) =3D=3D pid ) Im not sure if there is any posix way of describing how ptrace should be implemented but I know linux ptrace ignores the addr on DETACH. So my vote would be that ptrace ignores addr on detach to make it compatible with code for linux. With Regards Gunnar