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.
Created attachment 5937 [details] loop executable
Created attachment 5938 [details] libloop.so
commit 464379b appears to fix this problem.