Weirdness: is print_stack() supposed to work with ubacktrace() data?

Alain Kalker miki@dds.nl
Tue Nov 20 00:38:00 GMT 2012


While experimenting with application profiling, I copied the example 
from PR13714, but accidentally forgot to change print_stack to 
print_ustack. I ended up with this script:

global ubt

probe timer.profile { ubt[ubacktrace()] <<< 1 }

probe end {
     foreach (i in ubt+) {
         print_stack(i)
         printf("\t%d\n", @count(ubt[i]))
     }
}

Note the use of 'print_stack()' (which the docs say is for use with 
kernel stack backtraces) with the values in ubt (which are userspace 
backtraces) as parameter

I named the script 'myprofile.stp' and used it like this:
# stap -v myprofile.stp -d /lib/lib1.. -d /lib/lib2... -c "mycommand 
arg1 arg2"

and got a perfectly good summary of backtraces, in which most symbols 
were resolved.

I then realized (what I thought was) my error and changed 
'print_stack()' to 'print_ustack()', after which I only get hex backtraces.

My questions: why does 'print_stack()' apparently work with userspace 
backtraces in this example? Why does 'print_ustack()' not work?

Also, since the summary is generated at the 'end' probe, how can 
SystemTap know that the PC addresses to resolve are in fact from the 
process that has just exited?

Let's suppose another process, running after the first process exits, 
but before the 'end' probe hits, Let's say this process has PC addresses 
on its stack which just happen to be the same as some addresses of the 
first process.
Wouldn't 'print_stack()' then just (erroneously) list whatever symbols 
were found for the previous process?

Kind regards,

Alain



More information about the Systemtap mailing list