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
khaled has quit [Remote host closed the connection]
jhg__ has joined #systemtap
jhg_ has quit [Ping timeout: 268 seconds]
jhg__ is now known as jhg_
irker229 has quit [Quit: transmission timeout]
khaled has joined #systemtap
hpt has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
mjw has joined #systemtap
orivej has quit [Ping timeout: 258 seconds]
bendlas has quit [Remote host closed the connection]
mjw has quit [Ping timeout: 260 seconds]
mjw has joined #systemtap
orivej has joined #systemtap
mjw has quit [Quit: Leaving]
orivej has quit [Ping timeout: 240 seconds]
mjw has joined #systemtap
<agentzh>
happy holidays!
<fche>
so far so good!
<agentzh>
:)
* agentzh
is still busy playing stap.
<agentzh>
is it a good idea to make the "Build-id mismatch" error a warning?
<agentzh>
suppressing the check completely is not desired though.
<fche>
if the consequence of a buildid mismatch is the non-registration of a probe and a warning message, that's fine
<fche>
if it's a warning and then a mis-registration despite the mismathc, that's not fine :)
<fche>
an error to trigger the death of the script is probably not well advised
<agentzh>
i've noted during fork + execv, the error might get misfired.
<agentzh>
or in case of chroot or namespaced apps.
<fche>
hm fork/exec shouldn't affect this
<fche>
nor chroot/namespace
<agentzh>
when -x PID is not specified.
<fche>
if they run -different- binaries than expected, then yeah the buildids will mismatch, and stap should skip things
<agentzh>
just process(EXE).function(...) probes.
<agentzh>
yeah, different binaries in the chroot or namespaced env.
<agentzh>
the fork/exec thing is more like a race condition to me. adding -x PID makes it disappear.
<agentzh>
the mismatched build id is actually from the bash binary
<agentzh>
i've checked.
<agentzh>
different binaries but the same path.
<agentzh>
for the namespaced and chroot cases.
<agentzh>
yeah it should not register the probes, which is definitely an oops.
<agentzh>
that function still returns 1 if the check fails.
<agentzh>
and maybe we should change error:build-id to warning:buld-id as well?
<agentzh>
*build-id
orivej has joined #systemtap
<agentzh>
i've confirmed that with that patch, uprobes-inode still registers to the right executable inode.
<fche>
that error->warn bit looks fine
<fche>
sure, rename the man page
<agentzh>
cool, will commit.
<agentzh>
fche: i've also noted another thing: the try/catch block now overrides the MAXACTION error message so the source line location info always end up being the top-level try/catch statement's location.
<fche>
yeah. the NEWS bit could point out that this was always -effectively- a warning, we're just correcting the terminology as opposed to changing behaviour.
<fche>
which in turn suggests that maybe it's not worth putting into the NEWS at all
<agentzh>
fche: but it used to affect the exit code.
<agentzh>
i'll try the old version to confirm this again.
<agentzh>
i mean the exit code of staprun.
<fche>
hm yeah ok
<agentzh>
yeah i just checked the old version again. it indeed makes staprun exit with code 1
<agentzh>
that's what was bothering us.
<fche>
ok
<fche>
ship it
<agentzh>
cool thanks
<irker233>
systemtap: yichun systemtap.git:refs/heads/master * release-4.2-20-g4738dc2 / NEWS man/cs/error::buildid.7stap man/cs/warning::buildid.7stap man/error::buildid.7stap man/warning::buildid.7stap runtime/sym.c: The "Build-id mismatch" error now becomes a warning http://tinyurl.com/rkcx964
<fche>
ah need to tweak NEWS - post-4.2 things go in a higher section