From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: I'm attempting to use the ptrace() system call, but it fails randomly with 'No such process'. Version-Release number of selected component (if applicable): kernel-2.6.5-1.358 How reproducible: Always Steps to Reproduce: 1.Compile short test program 'ptracer' that does PTRACE_ATTACH, PTRACE_DETACH 2.Start some harmless program like 'xeyes' or something (pid=3855) 3.Repeat 'ptracer 3855' or whatever the pid for xeyes is. Actual Results: # ptracer 3855 ptrace(PTRACE_SYSCALL): No such process ptrace(PTRACE_DETACH): No such process # ptracer 3855 Status: 4991 # ptracer 3855 ptrace(PTRACE_SYSCALL): No such process # Expected Results: No error messages should be generated; process 3855 exists. Additional info: The annoying thing is that this comes and goes randomly. If I try (in tcsh) 'repeat 2000 ptracer 3855', it might not print anything, but if I run it by hand then every other run of it will barf. I also did 'repeat 20 ptracer 3855', and on some runs it barfed three times out of twenty, while running perfectly on others. Oh, and the window I started xeyes from reports 'Suspended (signal)' every time ptrace fails. This is all being done on my laptop, a Dell Inspiron 7500, running Fedora Core 2. I haven't updated the kernel yet.
Created attachment 102127 [details] Short demo program of the ptrace command Run this repeatedly to see random failures of the ptrace syscall.
Tested with the latest kernel: kernel-2.6.6-1.435.2.3, same problem.
Tested with the latest kernel: kernel-2.6.9-1.681_FC3, same problem.
Oh, I forgot to say that I've upgraded my laptop to FC3.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you.
While this bug has been closed, I would like to clarify, since support has gotten calls on this for RHEL 4: This is not a ptrace() bug. The test code fails to wait() between PTRACE_ATTACH and PTRACE_SYSCALL, and thus does not wait() before PTRACE_DETACH if PTRACE_SYSCALL errored out. This is correct behavior for ptrace(). ptrace() fails with ESRCH for these requests if the traced process was not stopped at the time, which perror() reports as meaning the process was not found, since that is considered the typical meaning of that error code.