This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tapsets/20075] target_set_pid() returns False when execve() syscall is successful


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]