Bug 165469

Summary: strace decodes nanosleep incorrectly as setup when attaching to running process
Product: Red Hat Enterprise Linux 4 Reporter: Joe Pruett <joey>
Component: straceAssignee: Stepan Kasal <kasal>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: RHEL4U3NAK
Fixed In Version: RHBA-2006-0418 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-10 21:18:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 181409    

Description Joe Pruett 2005-08-09 17:19:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050721 CentOS/1.0.6-1.4.1.centos4 Firefox/1.0.6

Description of problem:
if a running job is waiting in nanosleep attaching strace will report setup as the syscall being executed.

Version-Release number of selected component (if applicable):
strace-4.5.9-2.EL4

How reproducible:
Always

Steps to Reproduce:
1. perl -e 'sleep(100)' &
2. strace -p PID-OF-PERL-JOB
3.
  

Actual Results:  % perl -e 'sleep(100)' &
[2] 32603
% strace -p 32603
Process 32603 attached - interrupt to quit
setup( <unfinished ...>
Process 32603 detached
%


Expected Results:  strace should have reported nanosleep as the current syscall instead of setup.

Additional info:

this isn't just for perl.  a c program calling sleep will have the same result, perl is just easier for demostration.  running the process directly from strace will correctly report:
nanosleep({100, 0},  <unfinished ...>

Comment 1 Joe Pruett 2005-08-09 17:20:29 UTC
i forgot to add that i have not tested a newer version of strace to see if that
fixes the problem.

Comment 2 Dmitry V. Levin 2005-08-10 18:01:51 UTC
$ sleep 100 &
[1] 12345
$ strace -p $!
Process 12345 attached - interrupt to quit
nanosleep({100, 0},  <unfinished ...>
Process 12345 detached
$ strace -V
strace -- version 4.5.13


Comment 3 Roland McGrath 2005-10-12 04:53:04 UTC
RHEL4U2 has 4.5.13.

Comment 4 Joe Pruett 2005-10-19 01:07:34 UTC
rhel4u2 doesn't seem to fix it:

# rpm -q strace
strace-4.5.13-0.EL4.1
# sleep 100 &
[1] 32077
# strace -p 32077
Process 32077 attached - interrupt to quit
setup( <unfinished ...>
Process 32077 detached


Comment 7 Roland McGrath 2006-01-13 07:21:34 UTC
The name "setup" is wrong but what strace is doing is reporting what the kernel
tells it--system call 0, not the nanosleep system call number.  This happens
when the kernel restarts the nanosleep system call after a signal (the signal is
an unavoidable part of attaching strace).  The kernel does not leave any
information that strace can find about the original system call, only that the
special "restart_syscall" call is being made.  I've fixed strace upstream to
print this info more clearly:

restart_syscall(<... resuming interrupted call ...>) = 0


Comment 8 Joe Pruett 2006-01-13 17:12:40 UTC
is this a kernel problem in that it isn't reporting the system call?

Comment 9 Dmitry V. Levin 2006-01-13 19:41:08 UTC
Looks like 2.4.x reports the syscall while 2.6.x doesn't.

Comment 10 Roland McGrath 2006-01-13 19:46:08 UTC
This is in the kernel domain, yes.  It is not clear it can be called a "problem"
or that a kernel change can be expected.  At the low level, it is an accurate
report of what the process is doing--by the time you look at it, it is no longer
blocked in nanosleep system call, but is in fact blocked in the restart_syscall
system call.  

In 2.4, nanosleep does not back out and restart in the same way for signals,
so the issue does not arise.

Comment 14 Bob Johnson 2006-04-11 17:23:44 UTC
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.

Comment 19 Red Hat Bugzilla 2006-08-10 21:18:31 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0418.html