fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<agentzh>
fche: i'll check the actual session state.
<agentzh>
okay, it's 1 (STAP_SESSION_STARTING)
<agentzh>
the actual state
<agentzh>
tried many times, all have the state 1.
<agentzh>
i'll try making it also accept STAP_SESSION_STARTING.
amerey has quit [Quit: Leaving]
<agentzh>
fche: accepting STAP_SESSION_STARTING seems to work fine. at least using print_ubacktrace() in that probe context also works.
<agentzh>
should we do it that way? or making sure the callback is never fired this early?
<agentzh>
fche: so it is enter_be_probe's responsibility to set session state to STAP_SESSION_RUNNING? but stap_utrace_probe_handler() somehow may start running before enter_be_probe sets the session state?
khaled has quit [Quit: Konversation terminated!]
sscox has joined #systemtap
hpt has joined #systemtap
mjw has quit [Quit: Leaving]
<fche>
I'd look at how normal kprobes treat STARTING state.
<fche>
they are only willing to go through if STAP_SESSION_RUNNING
<fche>
interesting
<fche>
but probe begin requires STARTING
<fche>
I think we could make the case that the 'utrace' family of probes (process.begin) should also fire during STARTING
<fche>
if you wish to prototype that, agentzh, go for it; it'd be a user-visible change but a minor one so worth just a sentence in NEWS, probably not an explicit compatibility-check kind of thing (since it was stochastic in the first place)
<fche>
I'm really glad it's narrowed down to a state policy that's entirely within our administrative control, and not some sort of ugly timing bug somewhere deep in the runtime or the kernel
<fche>
good job
orivej has joined #systemtap
KDr2 has quit [Quit: Connection closed for inactivity]
<agentzh>
fche: without your guidance, i could not reach this far so quickly ;) yeah, i'll try drafting a patch for it.
_whitelogger has joined #systemtap
_whitelogger has joined #systemtap
orivej has quit [Ping timeout: 258 seconds]
khaled has joined #systemtap
hpt has quit [Ping timeout: 260 seconds]
sscox has quit [Ping timeout: 260 seconds]
mjw has joined #systemtap
wcohen has quit [Ping timeout: 258 seconds]
agentzh has quit [Ping timeout: 265 seconds]
agentzh has joined #systemtap
agentzh has quit [Changing host]
agentzh has joined #systemtap
wcohen has joined #systemtap
sscox has joined #systemtap
orivej has joined #systemtap
tromey has joined #systemtap
khaled has quit [Remote host closed the connection]
<fche>
hm a touch concerned about the printk -> dbug() replacements
<fche>
it could be all fine
<fche>
but hope that printk() wasn't chosen because dbug()-runtime-related functions were not safe to call from there
<fche>
but methinks it is okay
<fche>
my only complaint is that now perhaps there are too many dbug's
<fche>
like the routine state milestones in stap_task_finder_post_init
<fche>
looks like we'd have dozens of new lines per process now
<fche>
can you strip it down to a subset that is enough to point out a problem for further examination, as opposed to necessarily being sufficient for detailed study?
<fche>
or use parametrized levels of debugging
<fche>
(other dbug* macros compare a level number parameter to the -DDEBUG_FOO value
<fche>
similarly the new entryfn_prologue ... you could have one report that prints session_state() and the two expected statestr values, and let us infer if it would pass or fail
<fche>
not print a second report after the failure
<fche>
know what I mean?
gromero has joined #systemtap
<agentzh>
fche: yeah, understood. will adjust the patch accordingly.
<fche>
thanks dude. otherwise good to go, ship it
<agentzh>
okay, thanks
orivej has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
yog_ has quit [Ping timeout: 260 seconds]
tromey has quit [Quit: ERC (IRC client for Emacs 26.2)]
orivej has joined #systemtap
wcohen has quit [Ping timeout: 240 seconds]
sscox has quit [Ping timeout: 258 seconds]
<agentzh>
fche: does this look better? 20140.pts-7.nuc