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 runtime/14659] task_finder2 breaks ptrace apps


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.


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