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]

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


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


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