[Bug translator/12498] New: systemtap.examples/process/noptrace hangs on RHEL4 because arguments are wrong

["wcohen at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12498

           Summary: systemtap.examples/process/noptrace hangs on RHEL4
                    because arguments are wrong
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sources.redhat.com
        ReportedBy: wcohen@redhat.com


I was looking at why the tests were not completing on a i386 rhel4 system with
the linux 2.6.9-100.ELsmp kernel. Looking through the systemtap.log found that
noptrace.stp was the last running test. The end of systemtap.log would have the
following:

meta taglines 'test_installcheck: stap -g noptrace.stp -c 'strace -d ls'' tag
'test_installcheck' value 'stap -g noptrace.stp -c 'strace ls''


The tests hang there. If the "make installcheck" on the RHEL4 was put in the
background with a ^z and then put back in the foreground with "fg", the tests
would continue with:


attempting command stap -g noptrace.stp -c 'strace ls'
OUT strace[6259] ptrace(13082612) blocked: rc=0
strace[6257] ptrace(13082612) blocked: rc=0
strace[6257] ptrace(13082612) blocked: rc=0
strace[6257] ptrace(13082612) blocked: rc=0
chng_cpu.meta
chng_cpu.stp
cycle_thief.meta
cycle_thief.stp
...
RC 0
PASS: systemtap.examples/process/noptrace run


Commenting out the following line in syscall.ptrace seems to allow things to
continue:

         $request=0xbeef # anything invalid should do

Get a lot of output like:

strace[11378] ptrace(13082612) blocked: rc=0
strace[11376] ptrace(13082612) blocked: rc=0
strace[11376] ptrace(13082612) blocked: rc=0
strace[11376] ptrace(13082612) blocked: rc=0

the 13082612 value looks suspect.

ran following on RHEL4:

stap -e 'probe syscall.ptrace{printf("%s\n", $$parms)}' -c 'strace ls'

The $$parms look very wrong. lots of things like the following in the output

request=0xc79ff4 pid=0xffffffffbff1cdb8 addr=0x1 data=0x0
request=0xc79ff4 pid=0xffffffffbff1cd08 addr=0x2c data=0xffffffffbff1ccf8
request=0xc79ff4 pid=0xffffffffbff1cd28 addr=0x18 data=0xffffffffbff1cd18
request=0xc79ff4 pid=0xffffffffbff1cd28 addr=0x0 data=0xffffffffbff1cd18
request=0xc79ff4 pid=0xffffffffbff1cd28 addr=0x4 data=0xffffffffbff1cd18
request=0xc79ff4 pid=0xffffffffbff1cdb8 addr=0x1 data=0x0

On i386 rhel5 system the output looks much more reasonable:

request=0x3 pid=0x32d4 addr=0x2c data=0xffffffffbf8c63a8
request=0x3 pid=0x32d4 addr=0x18 data=0xffffffffbf8c63d8
request=0x3 pid=0x32d4 addr=0x0 data=0xffffffffbf8c63d8
request=0x3 pid=0x32d4 addr=0x4 data=0xffffffffbf8c63d8
request=0x18 pid=0x32d4 addr=0x1 data=0x0
request=0x3 pid=0x32d4 addr=0x2c data=0xffffffffbf8c63d8

Maybe this is due to the debuginfo being bad on the RHEL4 kernel.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.