Created attachment 5113 [details] test case that fails on my machine. I have encountered some very weird behavior where calling ptrace with PTRACE_GETEVENTMSG causes the variable passed as the pid to be set to 0 after the call. Certainly this is not the expected behavior since the documentation seems to indicate that the only "out" parameter is the data parameter. I've created a basic test case that triggers this issue on my system (gentoo linux x86-64, gcc-4.5.1, glibc-2.11.2-r3, gentoo-sources-2.6.34-r6). I will attach the test case that I've created. It uses a clone event to give reason to do a PTRACE_GETEVENTMSG ptrace request. Afterwards, the pid variable is set to 0 for some reason. PS: As a side note. I think I understand why ptrace is a variadic function as this enables variables of different types to be passed. But why is the pid passed as one of the variadic parameter? That parameter should always be of type pid_t right? I would have guessed that the prototype could just as easily be: long ptrace(enum __ptrace_request request, pid_t pid, ...); Thanks, Evan Teran
(In reply to comment #0) > I have encountered some very weird behavior where calling ptrace with > PTRACE_GETEVENTMSG causes the variable passed as the pid to be set to 0 after > the call. It completely depends on the way you compile your code because you added a buffer overrun in your code. The pointer passed to ptrace must be a long, not an int. Obviously you are damaging other variables. Why wouldn't you first make sure your code is correct before bothering others? Debugging byproxy is simpler, right?
It was not my intention to "debug by proxy". I did not realize that PTRACE_GETEVENTMSG required an unsigned long, without that particular detail the bug is unfortunately, non-obvious. I've re-read the man page and you are of course correct. Sorry for the invalid bug report.