This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/13200] New: apparent user-space memory corruption, unprivileged_myproc.exp


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

             Bug #: 13200
           Summary: apparent user-space memory corruption,
                    unprivileged_myproc.exp
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


We are experiencing apparent user-space memory corruption when running
process(SHLIB).function(ADDR).return probes, on rhel6-32.  See loop and
libloop.so binaries compiled from recent git sources, attached.  Test
with any recent systemtap version (1.4 or git):

sudo stap --unprivileged -e 'probe
process("libloop.so").function("libloopfunc").return { if (is_myproc ())
println ("is myproc") else println ("not myproc"); exit (); }' -c "./loop 1" -v 
Pass 1: parsed user script and 76 library script(s) using
22360virt/13508res/2384shr kb, in 190usr/70sys/248real ms.
Pass 2: analyzed script: 1 probe(s), 2 function(s), 3 embed(s), 0 global(s)
using 180580virt/15296res/3420shr kb, in 30usr/310sys/349real ms.
Pass 3: using cached
/root/.systemtap/cache/77/stap_772ab5d1f982c1e1f00873131f86e26d_2139.c
Pass 4: using cached
/root/.systemtap/cache/77/stap_772ab5d1f982c1e1f00873131f86e26d_2139.ko
Pass 5: starting run.
is myproc
Pass 5: run completed in 20usr/170sys/240real ms.

sudo stap --unprivileged -e 'probe process("libloop.so").function(0x41b).return
{ if (is_myproc ()) println ("is myproc") else println ("not myproc"); exit ();
}' -c "./loop 1" -v
Pass 1: parsed user script and 76 library script(s) using
22332virt/13496res/2384shr kb, in 170usr/70sys/243real ms.
Pass 2: analyzed script: 1 probe(s), 2 function(s), 3 embed(s), 0 global(s)
using 180816virt/15272res/3408shr kb, in 30usr/310sys/346real ms.
Pass 3: using cached
/root/.systemtap/cache/61/stap_61e14d704f6401d7f8821b136f5d557f_2021.c
Pass 4: using cached
/root/.systemtap/cache/61/stap_61e14d704f6401d7f8821b136f5d557f_2021.ko
Pass 5: starting run.
^CPass 5: run completed in 10usr/190sys/1774real ms.

The 0x41b address was that chosen by the testsuite on this rhel6-32 VM,
and is associated with "libloopfunc":

0000041b <libloopfunc>:
 41b:   55                      push   %ebp
 41c:   89 e5                   mov    %esp,%ebp
 41e:   90                      nop
 41f:   b8 00 00 00 00          mov    $0x0,%eax
 424:   90                      nop
 425:   83 c0 2d                add    $0x2d,%eax
 428:   3d c2 01 00 00          cmp    $0x1c2,%eax
 42d:   75 f5                   jne    424 <libloopfunc+0x9>


In the second run, the "loop" executable spins, as though the "1" argument
was lost.  Indeed, attaching a debugger to the process during pass 5, one
can see argc=0, argv=0, which is not right at all.

The effective difference between the two stap modules is:

<   STAP_PROBE_INIT(&probe_1999,
"process(\"/notnfs/BUILD/testsuite/libloop.so\").function(0x41b).return",
"process(\"/notnfs/BUILD/testsuite/libloop.so\").function(0x41b).return",
"<input>:1:1", " from: process(\"libloop.so\").function(1051).return"),
---
>   STAP_PROBE_INIT(&probe_1999, "process(\"/notnfs/BUILD/testsuite/libloop.so\").function(\"libloopfunc@.....").return", "<input>:1:1", " from: process(\"libloop.so\").function(\"libloopfunc\").return"),

<   { .address=(unsigned long)0x41eULL, .probe=(&stap_probes[0]), .return_p=1,
},
---
>   { .address=(unsigned long)0x41bULL, .probe=(&stap_probes[0]), .return_p=1, },

So for the broken case, the uretprobe is placed a few instructions too late,
as though it was subjected to prologue searching.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]