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

[Alain Kalker]

Op di 20 nov 2012 01:37:42 CET, Alain Kalker schreef:
> 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?

Forgot "the usual suspects":
OS: Ubuntu 12.10
Kernel package: linux-image-3.5.0-18-generic
Systemtap: version 2.1/0.153, commit release-2.0-87-gf4b122a