[Bug runtime/17127] systemtap sometimes fails to hook targets on busy systems

[Bug runtime/17127] systemtap sometimes fails to hook targets on busy systems

[jlebon at redhat dot com]

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

Jonathan Lebon <jlebon at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17127] New: systemtap sometimes fails to hook targets on busy systems

[jlebon at redhat dot com]

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.

[Bug runtime/17127] systemtap sometimes fails to hook targets on busy systems

[dsmith at redhat dot com]

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from David Smith <dsmith at redhat dot com> ---
Fixed in commit 386e80c.

The stap_task_finder_post_init() function was written to interrupt tasks that
were sleeping. In this case, the task is running. The task_finder2 code was
updated to only interrupt tasks that are in the TASK_INTERRUPTIBLE state.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17127] systemtap sometimes fails to hook targets on busy systems

[dsmith at redhat dot com]

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

--- Comment #2 from David Smith <dsmith at redhat dot com> ---
Note that bug #17181 reverted commit 386e80c (which both Jonathan and I were a
bit suspect of), and implements a real fix here.

-- 
You are receiving this mail because:
You are the assignee for the bug.