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]

RE: user mode backtrace


On Thursday, October 19, 2006 7:13 PM, Stone, Joshua I wrote:
> -----------------------------------------------
> global args
> probe syscall.open {
>     t = tid()
>     if (target() != t) next;
>     args[t] = argstr
> }
> probe syscall.open.return {
>     t = tid()
>     if (target() != t) next;
>     send_stop() // do this on return to avoid EINTR
>     printf("\n%d %s open(%s) = %s\n", t, execname(), args[t], retstr)
>     system(sprintf("pstack %d && kill -CONT %d", t, t))
>     delete args[t]
> }
> function send_stop() %{
>     send_sig(SIGSTOP, current, 1);
> %}
> -----------------------------------------------
> 
> ... and this one actually works!  Mostly... when I SIGSTOP an app
> started from an interactive shell, the shell seems to take back
> control, and I can't get SIGCONT to work nicely.  But, I tried
> targeting a gvim process, which is detached, and it worked just fine!
> 
> Of course, it's VERY slow -- probably orders of magnitude slower than
> other options like recording the stack frame for post-processing.
> 
> It's still a fun exercise though.  :)

Bonus points -

While this method is really too slow for tracing usage, it might be good
for debugging purposes.  I'm thinking of the usage model where you
detect that something interesting happens in your app, and you want to
pause it so you can attach a debugger and inspect it interactively.

For example, consider the simple case when you're debugging an app that
forks, and you want to have gdb attached to *both* ends of the fork.
The gdb docs guide you to "Put a call to sleep in the code which the
child process executes after the fork."  With SystemTap probes on
process.create and/or process.start, you could watch for your app's
fork, SIGSTOP the new process before it goes anywhere, and then attach a
gdb to the new process.  You still need multiple gdb sessions, but this
way you don't need to modify your app with a new sleep call.

If you want to be extra clever, you could even use system() to
automatically launch an xterm with a new gdb session attached, something
like:

  probe process.start {
    if (my_filter()) {
      send_stop()
      system(sprintf("xterm -e gdb %d &", tid()))
    }
  }


Josh


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