fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
mjw has quit [Quit: Leaving]
<kerneltoast> fche, erm
<kerneltoast> print_backtrace() doesn't even work on fedora 33 with 5.10
<kerneltoast> STAPCONF_KERNEL_READ_FILE_FROM_PATH appears to be totally borked
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
khaled has quit [Quit: Konversation terminated!]
hpt has joined #systemtap
orivej has joined #systemtap
fdalleau_away is now known as fdalleau
khaled has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
mjw has joined #systemtap
orivej has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
tromey has joined #systemtap
hpt has quit [Ping timeout: 240 seconds]
amerey has joined #systemtap
mjw has quit [Quit: Leaving]
orivej has joined #systemtap
mjw has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
orivej has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
<kerneltoast> fche, ya there?
zodbot has quit [Read error: Connection reset by peer]
fdalleau is now known as fdalleau_away
zodbot has joined #systemtap
<fche> hi
<kerneltoast> whaddya think about the above
<kerneltoast> is print_backtrace() working for you?
<fche> hm works on f33, so that's nioe
<kerneltoast> but I'm on f33
<fche> ok what are you seeing as in "not working" ?
<fche> and what kernel?
<kerneltoast> 5.10.16
<kerneltoast> not working = the backtrace is only 2 entries long, and they're only for the stap module itself
<kerneltoast> this is a broken backtrace:
<kerneltoast> 0xffffffffc08ff518 [stap_c58a93848a826c2bd4270962c3c2d1a1_6435+0x9518/0x0]
<kerneltoast> 0xffffffffc08ff579 [stap_c58a93848a826c2bd4270962c3c2d1a1_6435+0x9579/0x0] (inexact)
<fche> ok, backtracing the module itself is entirely correct
<kerneltoast> let me show you a working backtrace
<kerneltoast> working backtrace:
<kerneltoast> 0xffffffffc0a4b1db [stap_6ef2656a94d5ecc0dad8f89428dc017_41972+0xa1db/0x0]
<kerneltoast> 0xffffffffc0a4b330 [stap_6ef2656a94d5ecc0dad8f89428dc017_41972+0xa330/0x0]
<kerneltoast> 0xffffffffc0a460eb [stap_6ef2656a94d5ecc0dad8f89428dc017_41972+0x50eb/0x0]
<kerneltoast> 0xffffffffc0a4c7dc [stap_6ef2656a94d5ecc0dad8f89428dc017_41972+0xb7dc/0x0]
<kerneltoast> 0xffffffff9b758169 : proc_reg_write+0x39/0x60 [kernel]
<kerneltoast> 0xffffffff9b6db5b5 : vfs_write+0xa5/0x1a0 [kernel]
<kerneltoast> 0xffffffff9b6db82f : ksys_write+0x4f/0xb0 [kernel]
<kerneltoast> 0xffffffff9b40419b : do_syscall_64+0x5b/0x1a0 [kernel]
<kerneltoast> 0xffffffff9be000ad : entry_SYSCALL_64_after_hwframe+0x65/0xca [kernel]
<kerneltoast> 0xffffffff9be000ad : entry_SYSCALL_64_after_hwframe+0x65/0xca [kernel] (inexact)
<fche> fwiw on my 5.11.11-200.fc33.x86_64 kernel, the result looks like your long one
<kerneltoast> maybe kernel_read_file_from_path() got fixed
<kerneltoast> kernel_read_file_from_path() is erroring out for me
<kerneltoast> but stap doesn't print or return the error (bad fche)
<fche> errors are not welcome from backtraces
<fche> no sirree
<kerneltoast> at least a debug message would be noice
<fche> (they can happen too easily and transiently)
<kerneltoast> for DDEBUG_UNWIND
<kerneltoast> fche, it's not working for me on 5.11 either
<kerneltoast> 5.11.11-200.fc33.x86_64
<kerneltoast> same error when trying to read the .eh_frame file
<fche> ok I'm not seeing a systematic error here
<fche> can you give me repro instructions for what you're seeing?
<kerneltoast> install any kernel with kernel_read_file_from_path() in it
<kerneltoast> run `sudo stap -d kernel -e 'probe oneshot { print_backtrace() }'`
<kerneltoast> install debuginfo for that kernel
<kerneltoast> i'm just using the stock fedora kernel
<fche> my kernel is that way, and this generally works for me
<kerneltoast> i've tried on centos 8 and f33 with no luck
<fche> no luck meaning ... you never see the [kernel] fallback backtrace?
<kerneltoast> correct
<kerneltoast> and a colleague has this issue too on centos 8
<fche> I see it some fraction of the time
<fche> sth like 50%
<fche> ok so why do you suspect something is wrong with that particular function?
<kerneltoast> oh hey, you're right, it does work occasionally
<kerneltoast> i tracked it down to that function because _stp_module_self.eh_frame is 0
<kerneltoast> _stp_module_self.eh_frame gets populated from attrs.sections[i].address;
<kerneltoast> attrs.sections[i].address gets populated from read_sect_sysfs()
<kerneltoast> right inside get_module_sect_attrs()
<kerneltoast> and read_sect_sysfs() relies on kernel_read_file_from_path()
<kerneltoast> which returns an error for me
<kerneltoast> i added prints to every error path inside read_sect_sysfs() to see what was going on
<fche> you could run stap on kernel_read_file_* etc. to trace its internal op while another stap module is triggering the coded
<fche> just saying
<fche> you don't need all those printks
<kerneltoast> well i didn't know if it was kernel_read_file_* until i added the printks
mjw has quit [Quit: Leaving]