fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
gromero has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 276 seconds]
nkambo_ has joined #systemtap
hpt has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
gromero has quit [Ping timeout: 255 seconds]
irker502 has quit [Quit: transmission timeout]
_whitelogger has joined #systemtap
naveen has joined #systemtap
naveen has quit [Client Quit]
sanoj has joined #systemtap
sanoj has quit [Client Quit]
slowfranklin has joined #systemtap
naveen_ has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
sanoj has joined #systemtap
hpt has quit [Ping timeout: 248 seconds]
slowfranklin has quit [Quit: slowfranklin]
hpt has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 255 seconds]
hpt has quit [Ping timeout: 246 seconds]
hpt has joined #systemtap
<sj0rz>
\0/
slowfranklin has joined #systemtap
sanoj has quit [Ping timeout: 255 seconds]
hpt has quit [Ping timeout: 255 seconds]
sanoj has joined #systemtap
mjw has joined #systemtap
<sj0rz>
it seems that sometimes (but not always reliably for the same executable run), execve logs the first argument like this execve(0x55834dff1cec, [0x55834dff1cec, "/tmp/pidtree.sh"]
<sj0rz>
what could cause it do to that?
<sj0rz>
oh actually never mind, i think it might be in my custom script
<sj0rz>
oh actually i don't think so
<sj0rz>
this is just how argstr is set in execve, but just sometimes apparently
<sj0rz>
could there be some race going on here?
<sj0rz>
seems to happen on x86_64 and not on x86
gromero has joined #systemtap
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
scox has quit [Ping timeout: 255 seconds]
mbenitez has joined #systemtap
wcohen has quit [Ping timeout: 260 seconds]
<fche>
sj0rz, if the data is not paged in yet (like from a piece of the .text segment), then stap won't be able to copy the data; that happens on some short-lived programs
drsmith_away is now known as drsmith
<sj0rz>
fche thanks, that makes sense
<sj0rz>
this one is indeed extremely short lived
scox has joined #systemtap
<fche>
yeah, and linux is aggressive about not paging in data until required
<sj0rz>
so sometimes the data first gets paged in only after a pointer to it has been passed to a syscall and kernelland code tries to access it?
<sj0rz>
this is indeed static data from the executable in this case
<fche>
yup
<sj0rz>
so if i would try in the .return probe, it should be able to copy it?
<fche>
if e.g. the program printf()s or strdup()s those arguments before the exec, stap woudl probably see them
<sj0rz>
(can't in this case, since its execve)
<fche>
there is no .return from a successful execve :-)
<sj0rz>
check
<sj0rz>
hehe yeah exactly
<sj0rz>
would it be possible to have systemtap try to access the user memory in a way similar to the regular execve (e.g. one that would trigger the page to be mapped) ?
<fche>
not really; that would involve delaying a stap probe in progress while a page fault is handled
<fche>
well, not impossible just a lot of new work to try to do that safely
<sj0rz>
i have to confess i don't really know how kprobes works
<sj0rz>
i'll read up
<sj0rz>
thanks
<fche>
this would be uprobes, but yeah. stap disables interrupts/preemption etc. in order to run its probe handlers as atomically as possible
<sj0rz>
oh right
<fche>
so if we were to pull in some of this data, it'd have to be done -first-, before we switch to atomic processing
<fche>
hm, not impossible, just a fair bit of work, thinking about it
<sj0rz>
i'll see what i can make of the relevant parts of the code soon-ish
<sj0rz>
haven't seen a whole lot of stap code yet
slowfranklin has left #systemtap [#systemtap]
<fche>
yeah this is not easy stuff, I wouldn't wish it on a systemtap newbie :)
<sj0rz>
hehe fair
<fche>
but it would help if you were to open a bz rfe on the topic
<fche>
that way we don't forget the possibility at least
<sj0rz>
will do
<sj0rz>
i fixed that strace.stp missing execve call bug as well
<sj0rz>
will create a patch soon
<sj0rz>
(what is a bz rfe?)
<fche>
sourceware.org/bugzilla :)
<fche>
rfe = request for enhancement
<fche>
sorry about my acronym mania
<fche>
or as I say ... AM in the AM
<sj0rz>
haha check
naveen_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
naveen has joined #systemtap
scox has quit [Ping timeout: 248 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
sanoj has quit [Ping timeout: 248 seconds]
nkambo__ has quit [Ping timeout: 246 seconds]
tromey has joined #systemtap
nkambo__ has joined #systemtap
wcohen has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 268 seconds]
brolley has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 268 seconds]
mbenitez has quit [Quit: Leaving]
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
nkambo_ has joined #systemtap
scox has joined #systemtap
nkambo__ has quit [Ping timeout: 248 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 260 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 260 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
gila has joined #systemtap
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
naveen has quit [Quit: WeeChat 1.9]
gila has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]