Bug 128352 - ptrace system call is unreliable
ptrace system call is unreliable
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-21 21:05 EDT by Penelope Fudd
Modified: 2015-01-04 17:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 21:22:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Short demo program of the ptrace command (1.02 KB, text/plain)
2004-07-21 21:06 EDT, Penelope Fudd
no flags Details

  None (edit)
Description Penelope Fudd 2004-07-21 21:05:04 EDT
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.
Comment 1 Penelope Fudd 2004-07-21 21:06:47 EDT
Created attachment 102127 [details]
Short demo program of the ptrace command

Run this repeatedly to see random failures of the ptrace syscall.
Comment 2 Penelope Fudd 2004-07-23 15:19:40 EDT
Tested with the latest kernel: kernel-2.6.6-1.435.2.3, same problem.
Comment 3 Penelope Fudd 2005-02-13 16:59:21 EST
Tested with the latest kernel: kernel-2.6.9-1.681_FC3, same problem.
Comment 4 Penelope Fudd 2005-02-13 17:00:52 EST
Oh, I forgot to say that I've upgraded my laptop to FC3.
Comment 5 Dave Jones 2005-07-15 15:19:23 EDT
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.
Comment 6 Dave Jones 2005-10-02 21:22:56 EDT
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.
Comment 7 Chris Snook 2006-02-28 13:27:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.