Date: Thu, 29 Apr 2010 23:18:27 +0100 From: Bob Bishop <rb@gid.co.uk> To: Garrett Cooper <yanefbsd@gmail.com> Cc: freebsd-hackers@freebsd.org, Gunnar Hinriksson <tomtinn@gmail.com> Subject: Re: Ptrace segfault Message-ID: <9EF83DA6-B2D3-456E-B0AF-0B4F5F458A1F@gid.co.uk> In-Reply-To: <p2i7d6fde3d1004291437y9b789015ybf8153b41e034d9f@mail.gmail.com> References: <q2vcbb19c781004291206sc54fdb6ag53c3a763ad364e8e@mail.gmail.com> <p2i7d6fde3d1004291437y9b789015ybf8153b41e034d9f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On 29 Apr 2010, at 22:37, Garrett Cooper wrote:
> On Thu, Apr 29, 2010 at 12:06 PM, Gunnar Hinriksson =
<tomtinn@gmail.com> wrote:
>> Hello
>>=20
>> 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.
>>=20
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <sys/types.h>
>> #include <sys/ptrace.h>
>> #include <sys/wait.h>
>>=20
>> int main(int argc, char *argv[])
>> {
>> int pid =3D atoi(argv[1]);
>> ptrace(PT_ATTACH, pid, 0, 0);
>> wait(NULL);
>> ptrace(PT_DETACH, pid, 0, 0);
>> return 0;
>> }
>>=20
>> Am I using ptrace incorrectly or is there perhaps a bug in ptrace =
that
>> causes the child to always segfault ?
>=20
> Nope -- it's a bug in your code. =46rom ptrace(2):
>=20
> PT_CONTINUE The traced process continues execution. The addr =
argument
> is an address specifying the place where execution =
is to be
> resumed (a new value for the program counter), or
> (caddr_t)1 to indicate that execution is to pick up =
where
> it left off. The data argument provides a signal =
number to
> be delivered to the traced process as it resumes =
execution,
> or 0 if no signal is to be sent.
>=20
> [...]
>=20
> PT_DETACH This request is like PT_CONTINUE, except that it =
does not
=
^^^^^^^^^^^
> allow specifying an alternate place to continue =
execution,
=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and after it succeeds, the traced process is no =
longer
> traced and continues execution normally.
>=20
> Note 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 =
ptrace(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.org"
>=20
>=20
--
Bob Bishop +44 (0)118 940 1243
rb@gid.co.uk fax +44 (0)118 940 1295
mobile +44 (0)783 626 4518
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9EF83DA6-B2D3-456E-B0AF-0B4F5F458A1F>