fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
pwithnall_ has quit [Quit: pwithnall_]
wcohen has quit [Ping timeout: 240 seconds]
hpt has joined #systemtap
efiop has quit [Ping timeout: 255 seconds]
wcohen has joined #systemtap
sanoj has joined #systemtap
ravi_ has joined #systemtap
Humble has joined #systemtap
groleo has joined #systemtap
groleo1 has joined #systemtap
groleo has quit [Ping timeout: 255 seconds]
hkshaw has joined #systemtap
groleo1 has quit [Read error: Connection reset by peer]
Humble has quit [Remote host closed the connection]
mjw has joined #systemtap
nkambo has joined #systemtap
pwithnall____ has joined #systemtap
efiop has joined #systemtap
hpt has quit [Quit: Lost terminal]
Humble has joined #systemtap
wcohen has quit [Ping timeout: 255 seconds]
hkshaw has quit [Quit: Leaving.]
dmalcolm has quit [Ping timeout: 264 seconds]
sanoj has quit [Quit: Leaving]
ravi_ has quit [Quit: Leaving]
<p53ud0nym>
I have a kernel panic caused by an invalid read from the task 'stapio'. What information can you give me about this?
hkshaw has joined #systemtap
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
drsmith_away is now known as drsmith
hkshaw has quit [Ping timeout: 240 seconds]
brolley has joined #systemtap
<fche>
p53ud0nym, [man error::reporting] has some basic advice
drsmith is now known as drsmith_away
drsmith_away is now known as drsmith
wcohen has joined #systemtap
hkshaw has joined #systemtap
mjw has quit [Quit: Leaving]
hkshaw has quit [Ping timeout: 240 seconds]
tromey has joined #systemtap
jlebon has quit [Quit: leaving]
jlebon has joined #systemtap
<p53ud0nym>
I'm unable to compile a stap probe that calls the backtrace() function. I'm receiving a stack frame size error. Here is the error + stap-report: https://paste.debian.net/926897/
<fche>
interesting
<fche>
that error is one of the stap safety measures to avoid endangering the kernel while stap runs
<fche>
I don't have a good theory as to why this version of gcc should allow this situation this time ...
<fche>
but could try adding a "noinline " keywords to runtime/unwind.c line 1156
<fche>
so static noinline int unwind_frame ( ...)
<fche>
this is probably /usr/share/systemtap/runtime/unwind.c on your system
<fche>
don't have to recompile stap
<p53ud0nym>
no luck, i'm still getting the error.
<fche>
the same one? weird
<p53ud0nym>
Is there any way to override the cflags used? i.e. -Werror=frame-larger-than=
<fche>
there's no run-time flag. we could add one (e.g., suppress it in guru_mode)
<fche>
or just drop this part of buildrun.cxx (line 495ish)
<fche>
or run 'stap -k -p4' and hand-edit the Makefile in the saved temp directory
<p53ud0nym>
I tried -B -Wno-error to no avail
<p53ud0nym>
I'll try editing the makefile next
<fche>
yeah that too could work with the -k -p4 ... edit-makefile type of method
<fche>
this should not be necessary, needless to say. something's odd there. :(
<p53ud0nym>
fche: How would i then make the tapset after editing the makefile? (make didn't work)
<fche>
you'd run make -C /lib/modules/`uname -r`/build O=`pwd` modules from that directory
<fche>
IIRC
<fche>
make that M=
<fche>
p53ud0nym, any luck?
<p53ud0nym>
No, I'm currently recompling stap after increasing the stack frame limit to 1024 bytes.
<p53ud0nym>
@fche: Seems to have worked, but i need to reboot into another kernel.
jlebon_ has joined #systemtap
jlebon_ has quit [Client Quit]
<p53ud0nym>
Works ^^)
<fche>
ok, yeah, figured that would work
<fche>
but I don't know why so much space is newly required - or (sadly) how to find out why
<p53ud0nym>
I'm running a custom kernel with full debugging info, latest git version of stap.. and not much else.
<fche>
yeah. and it looks like the gcc version isn't that odd eitehr
<fche>
(fedora 25 has 6.3.1)
mjw has joined #systemtap
pwithnall_ has joined #systemtap
drsmith is now known as drsmith_away
drsmith_away is now known as drsmith
pwithnall_ has quit [Ping timeout: 252 seconds]
<p53ud0nym>
I have an error which is driving me nuts... I have a tapset whith a large number of probes in it (~15). When I add a probe to 'kernel.function("kmalloc")', it compilies and runs but silently isn't probing the other probes.
<p53ud0nym>
I can't find any max probe limit in the docs, is there?
<p53ud0nym>
s/other/original/g
<fche>
no limit like that
<fche>
(the 'tapset' term is one we reserve for the /usr/share/systemtap/tapset/ library, which normally contains probe aliases rather than probes)
<fche>
can you share your .stp file?
<p53ud0nym>
Yes, i've just confirmed the results.
<fche>
can you share the stp file?
<p53ud0nym>
fche: It's not currently useful - it's full of c, inline asm and other crap.
<p53ud0nym>
I can give you one of the stp files but it won't show anything...
<fche>
just curious to see what's up with those silently non-probed probes
<fche>
maybe they are only aliases (probe ALIAS = PROBEPOINT { } ) which are not probed/activated unless the script also has probe ALIAS { }
wcohen has quit [Ping timeout: 240 seconds]
<p53ud0nym>
fche: I may be abusing systemtap, but for your own interest here is the generated stp file that i'm using: https://transfer.sh/VeigT/tmp.8F36R3po5
<fche>
hey I'm certainly up for abuse
<fche>
but that url doesn't let me see the file :(
<p53ud0nym>
Really? It does for 2 of my machines on different IPs.
<fche>
switched to a less secure browser - now works
<fche>
which probes do you believe aren't firing ?
<p53ud0nym>
When I uncomment the last __kmalloc probe, the usb_bulk_msg and usb_conrol_msg probes don't fire.
<p53ud0nym>
I've tested it twice.
<fche>
and it's not like you're rmmod'ing or whatever? probes can only go into modules that are loaded (at some point)
<fche>
hm, it looks like you have 5 separate scripts, how are you running them?
<p53ud0nym>
correct, i'm not
<fche>
are some of them tapset files (in the systemtap proper sense?)
<fche>
then they get activated only if something in them is requested by the final end-user script
<fche>
so e.g.
<fche>
probe begin { } <--- will run without any tapset files being processed
<fche>
probe begin { warn("yo") } <---- will run pulling in one .stp file from the tapset, the one that defines the warn() function; also activates anything else in that same tapset file
<fche>
the [man stap] PROCESSING paragraphs describe the process generally
<fche>
so e.g. if your last file in that paste is the end-user script, and you comment out something in there that caused the other tapset files to be loaded, then those other files won't be loaded
<fche>
(and any probes in them won't be activated)
<p53ud0nym>
So yes, i've created my own lib folder with different "tapsets". However some "tapsets" contain probes in them. At the moment, I have a script to flatten all of the "tapsets" into a single file which gets compiled with `stap -p4 -g ...` .
<fche>
not sure you have the right model there - we don't flatten or compile -tapsets- - we compile end-user scripts (which incidentally pull in tapset files as needed)
<p53ud0nym>
So tapset is the wrong word for what i'm describing, essentially the file that I sent you gets passed to stap.
<p53ud0nym>
I flatten .stp files into a single source file. :)
jlebon has quit [Ping timeout: 252 seconds]
<irker291>
systemtap: rth systemtap.git:refs/heads/master * release-3.1-44-g7e2cd9f / : Squashed commit of the eBPF backend for stap http://tinyurl.com/n28tqh6
<p53ud0nym>
fche: solved compiling with --suppress-time-limits which I'd removed in trying to fix the stack frame size issue.
<fche>
single source file, got it, yes in that case every probe & associated functions should get compiled in
<fche>
btw you can see a little more of the internals if you do e.g. stap -v -p2 SCRIPT.stp -- you get back a pretty-printed representation of the final to-be-compiled batch of code
<p53ud0nym>
I appreciate your help, thanks. Anyway I'm going afk. cya.