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: systemtap userspace stack trace


On Tue, 2010-06-29 at 11:23 -0500, Tim Mooney wrote:
> The approach I had taken was to start with sigkill.stp and modify it as
> such:
> 
> probe signal.send {
>      if ( (sig_name == "SIGBUS") || (sig_name == "SIGSEGV") )
>          printf("Process exited with fatal signal\n");
> }
> 
> This works, but of course I discovered that it only prints kernel space
> info.  I need userspace, to try track down where in the daemon the problem
> is happening.
> 
> Is what I'm after even possible?

Unfortunately full user space backtraces from kernel space isn't done
yet. Working on it though. I did just finish support for better
usymname/data and normal ubacktrace support:
http://sourceware.org/bugzilla/show_bug.cgi?id=10599
that required accurate tracking of user space modules, so now we can at
least print the address and module of the current process. See the bug
report for some examples.

You can get full user space backtraces with the latest systemtap from
user space probes itself. See the print_ubacktrace() function in the
tapset reference manual: http://sourceware.org/systemtap/tapsets/
Hopefully soon also from some kernel contexts.

>   I understand that I could do something
> like:
> 
> probe process("lpd").function("*").call
> {
>     printf("=>%s(%s)\n", probefunc(), $$parms);
> }
> 
> probe process("lpd").function("*").return
> {
>    printf("<=%s:%s\n", probefunc(), $$return);
> }
> 
> probe signal.send {
>      if ( (sig_name == "SIGBUS") || (sig_name == "SIGSEGV") )
>          printf("Process exited with fatal signal\n");
>  		exit();
> }
>
> and just let it run, dumping lots of output to the terminal
> until the segfault, but I'm wondering if there's a better way?

Although that is as you say not very efficient, you can get a feeling
for what is going on like that. See also the para-callgraph.stp example:
http://sourceware.org/systemtap/examples/keyword-index.html#CALLGRAPH
To do the same as the above, run it as:

  stap para-callgraph.stp 'process("lpd").function("*")'

Another trick might be to store the last ubacktrace() in a global on
function entry and print it out with print_ustack() when receiving the
signal. This is also a bit slow, but involves less dumping.

Cheers,

Mark


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