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

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

[Alain Kalker]

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

Re: 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

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

[Alain Kalker]

Op 20-11-12 01:47, Alain Kalker schreef:
> Op di 20 nov 2012 01:37:42 CET, Alain Kalker schreef:
>> 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?
Self-answering my second question: yes, but my use of print_ustack is 
wrong. The docs do state that its argument should be the backtrace of 
the _current_ task. Better to use something like 'ubt[pid(), 
ubacktrace()] <<< 1', and filter out the backtraces where "pid == 
target()" later.