fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
jistone has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 258 seconds]
lkthomas has joined #systemtap
<lkthomas>
folks, is there have an example to see why a program is consuming all the CPU cycles ?
<lkthomas>
or in specific, is it possible to find out which function call causing that consumption ?
naveen_ has joined #systemtap
naveen_ has quit [Quit: WeeChat 1.9]
sanoj has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
gila has joined #systemtap
naveen_ has joined #systemtap
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
slowfranklin has joined #systemtap
gila has joined #systemtap
mjw has joined #systemtap
naveen_ has quit [Quit: WeeChat 1.9]
scox has quit [Ping timeout: 260 seconds]
hpt has quit [Quit: Lost terminal]
naveen_ has joined #systemtap
naveen_ has quit [Quit: WeeChat 1.9]
<sj0rz>
i'm trying to log the return value of execve, but "probe nd_syscall.*.return" only hits for execve when it failed and on "probe nd_syscall.*" the return value is not set yet
<sj0rz>
if i hook both then every execve call will produce two log entries
<sj0rz>
and i can never know if execve is going to return or not in the "probe nd_syscall.*"
<sj0rz>
it does not "see" successful ones at all since execve is not in the syscalls_nonreturn list, but adding it there would produce two entries for every execve
<sj0rz>
one containing only the retval, since it has then already run "delete thread_argstr[tid()]"
<sj0rz>
*produce two entries for every failed execve
<fche>
lkthomas, yeah, the pf* series of scripts can help with that:
<fche>
it's based on time-based sampling of backtraces
<fche>
execve doesn't return when it succeeds - that's a definition of its operation
<fche>
just like exit doesn't return
<sj0rz>
i know that
<sj0rz>
i just meant that the strace.stp script currently does not log execve at all when it succeeds
<sj0rz>
only when it fails
<sj0rz>
could've worded that more clearly ;p
<sj0rz>
i want to fix it, but i can't come up with a better way that logging the return value in a separate log entry
<fche>
aha. that'd be a script bug
<fche>
yeah I'd put execve into _nonreturn
<fche>
or make a new _mayreturn group
<fche>
just _nonreturn alone should do actually
<sj0rz>
indeed
<sj0rz>
this is what a failed call looks like then:
<sj0rz>
i guess i could fix report() to check if the thread_argstr[pid] has already been deleted and then print only the return value, and a newline otherwise
<fche>
the thing that looks odd in that report to me is the equal sign for a nonreturn syscall
<fche>
maybe report() could be sensitive to nonreturn-ness; that could be enough