public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/14659] task_finder2 breaks ptrace apps
Date: Mon, 08 Oct 2012 19:06:00 -0000	[thread overview]
Message-ID: <bug-14659-6586-bqr34vuqKP@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-14659-6586@http.sourceware.org/bugzilla/>


http://sourceware.org/bugzilla/show_bug.cgi?id=14659

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #1 from David Smith <dsmith at redhat dot com> 2012-10-08 19:06:29 UTC ---
I've been looking at this one.  At first I thought it might be related to
runtime/stp_utrace.c's use of the TASK_TRACED flag, but even without that, the
example in this testcase still failed.

Here's what the testcase breaks down to:

====
# stap -vp2 -e 'probe never{print_ubacktrace()}' -c 'strace -e read true'
Pass 1: parsed user script and 89 library script(s) using
202528virt/22076res/2772shr/19600data kb, in 180usr/50sys/237real ms.
# functions
print_ubacktrace:unknown ()
%{ /* pragma:unwind */ /* pragma:symbols */
/* myproc-unprivileged */ /* pragma:uprobes */ /* pragma:vma */
    _stp_stack_user_print(CONTEXT, _STP_SYM_FULL);
%}
# probes
never /* <- never */
print_ubacktrace()
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s)
using 203060virt/22848res/3040shr/20132data kb, in 0usr/0sys/12real ms.
+===

So, the print_ubacktrace() function uses several pragmas.  I've narrowed things
down to the following script which gets the same error:

====
# functions
function doit()
%{ /* pragma:vma */

    _stp_print("never\n");
%}

# probes
probe never {
      doit()
}
====

The vma pragma turns on vma tracking in task_finder2, which turns on syscall
tracing. I'll bet that is what is interfering with ptrace().

When doing syscall tracing, task_finder2 attaches to the 'sys_enter' and
'sys_exit' tracepoints. Setting a handler on those tracepoints sets the
TIF_SYSCALL_TRACEPOINT task flag, which gets checked along with the
TIF_SYSCALL_TRACE task flag (which ptrace uses) in _TIF_WORK_SYSCALL_MASK.

Here's a syscall tracing test that shows similar behavior:

====
# stap -v -e 'probe process.syscall{printf("%d\n", $syscall)}' -c 'strace -e
read true'
Pass 1: parsed user script and 89 library script(s) using
204748virt/22196res/2856shr/19720data kb, in 170usr/50sys/232real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 1 embed(s), 0 global(s)
using 205276virt/22968res/3128shr/20248data kb, in 0usr/0sys/6real ms.
Pass 3: translated to C into
"/tmp/stappzFQd4/stap_31c0780e9dc65829f8476ec5a54fb52b_1254_src.c" using
205276virt/23300res/3432shr/20248data kb, in 0usr/0sys/1real ms.
Pass 4: compiled C into "stap_31c0780e9dc65829f8476ec5a54fb52b_1254.ko" in
2940usr/1620sys/5112real ms.
Pass 5: starting run.
--- SIGTRAP {si_signo=SIGTRAP, si_code=0x5, si_pid=12793, si_uid=5183} ---
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP (core dumped) +++
Warning: child process exited with signal 5 (Trace/breakpoint trap)
15
13
14
59
59
59
59
12
9
21
2
5
9
3
2
0
5
9
10
9
9
3
9
9
158
10
10
10
11
13
39
63
12
12
12
102
104
56
61
101
101
61
101
61
62
101
61
101
101
61
101
61
231
4
4
4
4
4
56
13
13
13
13
13
13
13
14
14
14
61
101
14
101
101
1
101
14
61
14
101
1
101
14
61
14
1
160
13
234
WARNING: /usr/local/bin/staprun exited with status: 1
Pass 5: run completed in 20usr/220sys/703real ms.
Pass 5: run failed.  Try again with another '--vp 00001' option.
====

I'll think about ways to avoid syscall tracing when doing vma tracking.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

  reply	other threads:[~2012-10-08 19:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03  1:09 [Bug runtime/14659] New: " jistone at redhat dot com
2012-10-08 19:06 ` dsmith at redhat dot com [this message]
2012-10-08 19:26 ` [Bug runtime/14659] " jistone at redhat dot com
2012-10-08 20:43 ` dsmith at redhat dot com
2012-10-08 21:03 ` dsmith at redhat dot com
2012-10-11 15:58 ` dsmith at redhat dot com
2012-10-11 22:30 ` agentzh at gmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-14659-6586-bqr34vuqKP@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).