This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/13200] New: apparent user-space memory corruption, unprivileged_myproc.exp
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 19 Sep 2011 15:13:00 +0000
- Subject: [Bug translator/13200] New: apparent user-space memory corruption, unprivileged_myproc.exp
- Auto-submitted: auto-generated
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.