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
orivej has joined #systemtap
irker164 has quit [Quit: transmission timeout]
slowfranklin has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
mjw has joined #systemtap
hpt has quit [Ping timeout: 255 seconds]
gila has joined #systemtap
higgins has quit [Quit: Leaving]
higgins has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
khaled has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
mjw has quit [Quit: Leaving]
slowfranklin has joined #systemtap
hpt has joined #systemtap
wcohen has quit [Ping timeout: 250 seconds]
hpt has quit [Ping timeout: 245 seconds]
sscox has joined #systemtap
wcohen has joined #systemtap
tromey has joined #systemtap
irker967 has joined #systemtap
<irker967> systemtap: fche systemtap.git:refs/heads/master * release-4.0-124-g18d1bac / session.cxx: session.cxx diagnostics: don't dump kernel_functions below verbose=6 http://tinyurl.com/yxbepqun
<fche> wcohen, if you still happen to have access to an arm64 box
<wcohen> fche, yes I do.
<fche> would you be able to give a quick test to BZ1658163, to see what might be going on?
<fche> so -DDEBUG_UNWIND -DDEBUG_SYMS etc. kind of data gathering would be good
<wcohen> the arm64 box I have is running fedora 29 4.20.10 kernel and a git build of systemtap. the rhbzZ1658163 on this environment gives the same abbreviated backtrace.
<fche> ok, should be useful to get the similar info then
<wcohen> fche, added a comment with the run with --DEBUG_UNWIND -DDEBUG_SYMS to BZ1658163
<wcohen> fche, I vaguely remember some issues with backtraces aarch64 backtraces some years ago.
* wcohen trying to look up discussion on that.
<fche> -DDEBUG_SYMBOLS rather than DEBUG_SYMS, and maybe -DDEBUG_TRANS please
<fche> basically we should see what kernel stext / module addresses are being sent to the stap module
<fche> 2016 yuck
slowfranklin has left #systemtap [#systemtap]
<fche> the eh_frame data alone should be fine (if slow), but it seems as though not even that was working here
dmalcolm has quit [Remote host closed the connection]
<wcohen> fche, yes, they may not be the same root cause.
<wcohen> fche, attached stap results as an attachment to the bz. anything look odd in the output?
<wcohen> want me to set some additional defines or flags for the run?
<fche> yes, -DDEBUG_SYMBOLS and -DDEBUG_TRANS please
dmalcolm has joined #systemtap
<wcohen> I attached the output to the wrong bz. take another look at 1658163, fche.
<fche> thanks
<wcohen> towards the end of stap_results.out it says:
<wcohen> unwind:1490: pc=ffff0000082de7e8, ffff0000082de7e8
<wcohen> unwind_frame:1190: Module /usr/lib/debug/usr/lib/modules/4.20.10-200.fc29.aarch64/vmlinux: no unwind frame data
<wcohen> unwind:1537: debug_frame failed: -5, trying eh_frame
<wcohen> unwind:1533: trying debug_frame
<wcohen> unwind_frame:1190: Module /usr/lib/debug/usr/lib/modules/4.20.10-200.fc29.aarch64/vmlinux: no unwind frame data
<wcohen> are the "no unwind frame data" expected?
<wcohen> I am wondering if there might be some kernel config change that caused aarch64 backtraces to stop working.
<fche> would look at the hex address from first principles
<fche> that 0xffff0000082de7e8 number should fit into one of the ranges used by the modules
<fche> or a sym within the kernel itself; does /proc/kallsyms contain addresses in that range?
slowfranklin has joined #systemtap
<wcohen> fche, that is definitely the start of the kmem_cache_alloc function in the kernel.
slowfranklin has quit [Client Quit]
<wcohen> fche, adding nokaslr to the kernel command line didn't make difference.
<fche> what does a stap -k .... stap-symbols.h look like w.r.t. the kernel eh-frame data? it should contain some relocation info
<fche> near the bottom of the file
<wcohen> there doesn't seem to be much eh_frame data.
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
slowfranklin has quit [Client Quit]
slowfranklin has joined #systemtap
vbernat has quit [Quit: The future belongs to those who believe in the beauty of their dreams.]
vbernat has joined #systemtap
irker967 has quit [Quit: transmission timeout]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
orivej has quit [Ping timeout: 246 seconds]
tromey has quit [Ping timeout: 240 seconds]
slowfranklin has quit [Quit: slowfranklin]
wcohen has quit [Ping timeout: 268 seconds]