rb at gid.co.uk
Thu Apr 29 22:23:05 UTC 2010
On 29 Apr 2010, at 22:37, Garrett Cooper wrote:
> On Thu, Apr 29, 2010 at 12:06 PM, Gunnar Hinriksson <tomtinn at gmail.com> wrote:
>> 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 <stdio.h>
>> #include <stdlib.h>
>> #include <sys/types.h>
>> #include <sys/ptrace.h>
>> #include <sys/wait.h>
>> int main(int argc, char *argv)
>> int pid = atoi(argv);
>> ptrace(PT_ATTACH, pid, 0, 0);
>> ptrace(PT_DETACH, pid, 0, 0);
>> return 0;
>> Am I using ptrace incorrectly or is there perhaps a bug in ptrace that
>> causes the child to always segfault ?
> Nope -- it's a bug in your code. From ptrace(2):
> 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.
> 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.
> 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 != (caddr_t)1, or
(b) ignore addr entirely; it's not clear which.
OP inferred (b) which is reasonable.
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
Bob Bishop +44 (0)118 940 1243
rb at gid.co.uk fax +44 (0)118 940 1295
mobile +44 (0)783 626 4518
More information about the freebsd-hackers