This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/20075] target_set_pid() returns False when execve() syscall is successful
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 11 May 2016 16:54:43 +0000
- Subject: [Bug tapsets/20075] target_set_pid() returns False when execve() syscall is successful
- Auto-submitted: auto-generated
- References: <bug-20075-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20075
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dsmith at redhat dot com,
| |jistone at redhat dot com
--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
Interesting. You can see this directly if you probe process.begin and
process.end yourself -- the end is called before the execve return, and the
begin is called after.
I believe for our internal process tracking, we report process.end right away,
but the process.begin waits for a quiescent point where it's sleepable, which
will be very low in the kernel entry code. So your execve return is happening
in a gray area where we're not really "attached" to that process any more.
I'm not sure if there's any way to make that more seamless. Perhaps we could
hold off the process.end until it quiesces too? David, what do you think?
As a workaround, you can simplify your return filtering based just on whether
you saw the same entry -- if (tid() in thread_argstr) { report(...) } -- and in
the call you should also wait to write that entry until after the filter
passes.
--
You are receiving this mail because:
You are the assignee for the bug.