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

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.


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