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 runtime/17127] New: systemtap sometimes fails to hook targets on busy systems


https://sourceware.org/bugzilla/show_bug.cgi?id=17127

            Bug ID: 17127
           Summary: systemtap sometimes fails to hook targets on busy
                    systems
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

When the system is stressed, it seems like systemtap is unable to trace the
target process and just hangs there:

In the first terminal:

$ cat mytestcase.c
int foo(void) {
   return 0;
}
int main(void) {
   while (1)
      foo();
}
$ gcc -g -o mytestcase.x mytestcase.c
$ ./mytestcase.x

In a second terminal:

$ stap -ve 'probe process("./mytestcase.x").function("foo") { println("
hit"); exit() }'
Pass 1: parsed user script and 102 library script(s) using
214960virt/30220res/3012shr/27904data kb, in 100usr/0sys/1035real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s)
using 215488virt/31564res/3596shr/28432data kb, in 0usr/0sys/35real ms.
Pass 3: translated to C into
"/tmp/stapiAxUFV/stap_6f608244bf56e10421d6bd9075768a45_1504_src.c" using
215604virt/32144res/4036shr/28548data kb, in 10usr/60sys/619real ms.
Pass 4: compiled C into "stap_6f608244bf56e10421d6bd9075768a45_1504.ko" in
1340usr/150sys/17389real ms.
Pass 5: starting run.
hit
Pass 5: run completed in 10usr/10sys/503real ms.
$

Here stap works as expected. Now let's make the system busy. In a third
terminal:

$ while [ true ]; do /bin/echo -n '#'; done

Now back to the second terminal, run stap again. It will start the run but fail
to detect a hit:

$ stap -ve 'probe process("./mytestcase.x").function("foo") { println("hit");
exit() }'
Pass 1: parsed user script and 102 library script(s) using
214952virt/30224res/3012shr/27896data kb, in 100usr/10sys/1441real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s)
using 215480virt/31564res/3596shr/28424data kb, in 0usr/0sys/39real ms.
Pass 3: using cached
/home/vm/.systemtap/cache/6f/stap_6f608244bf56e10421d6bd9075768a45_1504.c
Pass 4: using cached
/home/vm/.systemtap/cache/6f/stap_6f608244bf56e10421d6bd9075768a45_1504.ko
Pass 5: starting run.
^C

This is the case even after we stop the while loop. So it seems like there's
something during the start-up process that is sensitive to system activity.

-- 
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]