This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/14659] task_finder2 breaks ptrace apps
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 08 Oct 2012 21:02:41 +0000
- Subject: [Bug runtime/14659] task_finder2 breaks ptrace apps
- Auto-submitted: auto-generated
- References: <bug-14659-6586@http.sourceware.org/bugzilla/>
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.