fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
gromero has joined #systemtap
gromero has quit [Ping timeout: 256 seconds]
hpt has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
hpt_ has joined #systemtap
hpt has quit [Ping timeout: 244 seconds]
slowfranklin has joined #systemtap
irker957 has quit [Quit: transmission timeout]
orivej has joined #systemtap
sanoj has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
slowfranklin has quit [Quit: slowfranklin]
hpt has joined #systemtap
hpt_ has quit [Ping timeout: 240 seconds]
hpt has quit [Ping timeout: 260 seconds]
hpt has joined #systemtap
hpt has quit [Remote host closed the connection]
hpt has joined #systemtap
hpt has quit [Ping timeout: 260 seconds]
hpt has joined #systemtap
aryehw has joined #systemtap
lightydo has joined #systemtap
hpt_ has joined #systemtap
pwithnall has joined #systemtap
hpt has quit [Ping timeout: 265 seconds]
slowfranklin has joined #systemtap
mjw has joined #systemtap
pwithnall has quit [Read error: Connection reset by peer]
<fche>
the first one looks good, up to the point of the python interpreter; you'd get more data if you add the python binary / solibs (see also stap --ldd)
<fche>
the second set - is the question why the userspace backtraces don't go into the /lib/x86_64-linux-gnu/libc-2.23.so file properly?
<jhg_>
Hi Frank!
<fche>
not sure why that'd be - your stap -d flag looks sound ... maybe there is a version mismatch, or maybe that solib is stripped of unwind data?
<jhg_>
I am confused about 0xffff8805b3d9fd00 at line 6 and 31
<fche>
duuuuude
<jhg_>
also, I should be seeing grab_cache_page_write_begin() called by afs_linux_write_begin(), but this does not appear to occur...
<fche>
aha, that address looks almost like a data address - or maybe another module?
<fche>
note also that inlined functions may or may not appear properly in this sort of traceback
<fche>
might want to do stap --all-modules --ldd"
<fche>
as a matter of course, so all modules and all solibs of named executables are all pulled in
<fche>
(a compiler can still inline a copy if it likes, but yeah)
<fche>
another thing worth considering is running with stap -DDEBUG_UNWIND=1 or even =2
<fche>
stap is pretty vigorous about trying to unwind via different mechanisms so if unwind data is broken, it can switch to frame-pointer heuristics ... dunno about vice versa
<jhg_>
hmm... that's true. which could explain why I see it referenced by this generic_perform_write()+0xce offset.. even though generic_perform_write() does not directly call grab_cache_page_write_begin() afaict
<fche>
but yeah, it's best-effort
<jhg_>
still no love on that weird line 6 memory address
<jhg_>
I can't even find it in /proc/kallsyms
<fche>
looks like a data area
<jhg_>
corrupt stack?
<fche>
more like maybe imperfect unwind data
<fche>
I wouldn't suspect actual corruption to working kernel data from just this
aryehw has quit [Ping timeout: 268 seconds]
tromey has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
slowfranklin has left #systemtap [#systemtap]
aryehw has joined #systemtap
agilo has joined #systemtap
<agilo>
hi there, what level of access would be required on a machine to see that systemtap is running? or asked another way, how could you hide the presence of systemtap?
<agilo>
can systemtap trace processes running in a virtual machine?
gromero has joined #systemtap
<fche>
agilo, will be with you in 10ish mins
<agilo>
thx :)
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
sanoj has joined #systemtap
orivej_ has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
aryehw has quit [Ping timeout: 256 seconds]
<jhg_>
interesting. perf-tool does not show the weird address nor file_update_time() in the backtrace.
orivej_ has quit [Ping timeout: 256 seconds]
slowfranklin has joined #systemtap
pwithnall has quit [Ping timeout: 240 seconds]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
agilo has quit [Ping timeout: 252 seconds]
pwithnall has joined #systemtap
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
sanoj has quit [Ping timeout: 240 seconds]
pwithnall_ has joined #systemtap
pwithnall_ has quit [Remote host closed the connection]
orivej has joined #systemtap
pwithnall has quit [Ping timeout: 264 seconds]
mjw has quit [Quit: Leaving]
_whitelogger has joined #systemtap
mjw has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 26.1.50)]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
wcohen_ has quit [Ping timeout: 256 seconds]
brolley has left #systemtap [#systemtap]
<jhg_>
fche: under what circumstances can we have a calling function not appear in the stack trace of a child function? someone had mentioned reusing a stack frame pointer, but that seems a bit too magical to me at the moment.