[Bug runtime/14659] task_finder2 breaks ptrace apps
dsmith at redhat dot com
sourceware-bugzilla@sourceware.org
Mon Oct 8 21:03:00 GMT 2012
http://sourceware.org/bugzilla/show_bug.cgi?id=14659
--- Comment #4 from David Smith <dsmith at redhat dot com> 2012-10-08 21:02:41 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > If there's really a problem between the kernel's syscall tracing and ptrace,
> > then we should report this as a kernel bug. But right now, it seems like
> > there's more going on...
>
> Looks like you are right that it isn't syscall probing directly.
>
> Looking back at the test script I posted earlier:
>
> ====
> # functions
> function doit()
> %{ /* pragma:vma */
>
> _stp_print("never\n");
> %}
>
> # probes
> probe never {
> doit()
> }
> ====
>
> That script causes the bad SIGTRAP behavior. However, if I stub out
> _stp_vma_init() and _stp_vma_done() I don't see the SIGTRAPs.
>
> So, it isn't the syscall tracing in the vma tracking stuff, but it is something
> else that the vma tracking does.
After poking this a bit more, it could be that stubbing out _stp_vma_init()
also removes the only task_finder client, so it doesn't do anything.
I get the following output with a simple process.begin probe:
===
stap -e 'probe process.begin { printf("%s\n", execname()) }' -c 'strace -e read
true'
+++ exited with 0 +++
stapio
strace
strace
strace
true
===
Here we don't get the SIGTRAP, but we don't get strace's output either.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Systemtap
mailing list