public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Stone, Joshua I" <joshua.i.stone@intel.com>
To: "SystemTap" <systemtap@sources.redhat.com>
Cc: <david_list@boreham.org>, 	"Frank Ch. Eigler" <fche@redhat.com>
Subject: RE: user mode backtrace
Date: Fri, 20 Oct 2006 18:34:00 -0000	[thread overview]
Message-ID: <C56DB814FAA30B418C75310AC4BB279DCC41E0@scsmsx413.amr.corp.intel.com> (raw)

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

             reply	other threads:[~2006-10-20 18:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-20 18:34 Stone, Joshua I [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-10-20  2:13 Stone, Joshua I
2006-10-20  2:02 Stone, Joshua I
2006-10-19 22:56 Stone, Joshua I
2006-10-19 23:07 ` David Boreham
2006-10-19 23:24 ` David Boreham
2006-10-20  0:09 ` Frank Ch. Eigler
2006-10-19 20:47 David Boreham
2006-10-19 22:33 ` Vara Prasad
2006-10-19 22:51   ` David Boreham
2006-10-20 14:28     ` William Cohen
2006-10-20 14:50       ` David Boreham
2006-10-19 23:50 ` Frank Ch. Eigler
2006-10-20  0:15   ` David Boreham
2006-10-20  0:27     ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C56DB814FAA30B418C75310AC4BB279DCC41E0@scsmsx413.amr.corp.intel.com \
    --to=joshua.i.stone@intel.com \
    --cc=david_list@boreham.org \
    --cc=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).