Bug 91085 - strace hangs and gives bad info for NPTL fork()
Summary: strace hangs and gives bad info for NPTL fork()
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: strace   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Roland McGrath
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-17 16:00 UTC by John Reiser
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-04 18:58:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John Reiser 2003-05-17 16:00:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
Running "strace -f nptl/tst-fork3" hangs in idle.  The strace output mentions
non-existent flag CLONE_IDLETASK.  The report for fork() implemented using
clone() has entirely the wrong flags.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Build the glibc internal testcase nptl/tst-fork3 .
2. Run "strace -f nptl/tst-fork3 2>strace.out &" in background, and notice that
it never exits.  The non-straced tst-fork3 exits very quickly.
3. Inspect strace.out for the second call to clone(), which is implementing
fork().  This instance can be identified by child_stack==0.
4. Run "grep CLONE_IDLETASK /usr/include/*/*.h".

Actual Results:  strace hangs in idle.
[15942], {entry_number:6, base_addr:0x40835d30, limit:1048575, seg_32bit:1,
contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) =
[pid 15942] clone(child_stack=0,
= 15943     ### flags are totally wrong; actual value is 0x1200011 .
[pid 15943] clone(child_stack=0x41036950,
= 15944
No output from the grep for CLONE_IDLETASK.

Expected Results:  strace exits normally.
Second clone() has only two flags  CLONE_CHILD_CLEARTID | CLONE_CHILD_SETTID ,
plus SIGCHLD; the value in %ebx is 0x1200011.

Additional info:

Comment 1 Roland McGrath 2003-05-23 01:09:16 UTC
I did not see the hanging failure mode, but the bug corrupts syscall arguments
and so a variety of failure modes are possible.  I've found and fixed the bug in
the upstream strace sources.  There will be an errata version as soon as possible.

Comment 2 P Fudd 2003-06-01 21:50:57 UTC
Perhaps this is why 'strace -fp <pid>' is failing for me:
# ps aux | grep httpd
# strace -fp 9627
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
detach: ptrace(PTRACE_DETACH, ...): Operation not permitted

redhat 9, strace-4.4.95-2, default 2.4.20-8 kernel, updated httpd-2.0.40-21.1

Comment 3 Roland McGrath 2003-06-02 18:23:31 UTC
That's very possible.  Using strace on strace would show you the PIDs it uses
in the ptrace calls that fail.  If it is using bogus PID values, then that is 
probably the same bug.

Comment 4 P Fudd 2003-06-02 22:12:16 UTC
Something I discovered was that if I do strace -fp <pid>, and if I get that
error, the process in question is put into 'T' state in a ps listing.  Traced or
stopped, according to the man page.

Something *really* neat occurred when I tried 'strace -fo/tmp/a strace -fp
<pid>' (or somesuch)... that httpd process is not only in 'T' state, but it's
unkillable, even with a kill -9.

Did you say there was a new rpm for strace available somewhere?  

Comment 5 Roland McGrath 2003-06-04 18:58:20 UTC
There is a new strace version now available in rawhide.
There will be an errata release for RHL9 at some point as well.

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