* Srikar Dronamraju <sri...@linux.vnet.ibm.com> [2009-03-03 18:56:53]:
> Hi Roland,
>
> Here is analysis of the bug 9826. Can you please let me know your
> thoughts?
>
> Summary of the problem:
> Probing a program started by gdb causes the traced program to receive
> thousounds of SIGSEGV signals.
>
> Consider two engines, first engine(gdb) which hasn't inserted any
> breakpoints and second engine(uprobes) has inserted one breakpoint. On
> hitting a breakpoint,first engine(gdb) sets a UTRACE_STOP action while
> the second engine (uprobes) sets a UTRACE_SINGLESTEP action. The second
> engine also shows interest in "quiesce" event. The quiesce handler would
> return UTRACE_SINGLESTEP if the quiesce were to happen after the
> UTRACE_SINGLESTEP has been requested.
>
> As expected this results in the traced program being stopped. Once the
> traced process is resumed, the UTRACE_SINGLESTEP action seems to be
> ignored. Is this expected?
>
> 1. How do we avoid singlestep from being ignored after resume?
> 2. Shouldn't gdb be interested only in breakpoint events that it has set
> earlier?
> 3. Is there a way for the engines to communicate to other engines that
> these engines and events are exclusively for itself and other engines
> need not bother?
>
> This is on a Fedora 10 kernel.
>
> Details:
> 1. stap -ve 'probe process("ls").function("main") { print("hello world\n") }'
>
> 2. (In another window) gdb /bin/ls
>
> 3. run at gdb prompt.
>
> A. uprobes has inserted one breakpoint.
> B. gdb has not inserted any breakpoints.
> C. Once breakpoint gets hit.
> I. ptrace engine (gdb) thro report_signal callback
> (ptrace_report_signal()) (gdb) sets the action to
> UTRACE_STOP.
>
> II. report_signal (uprobes) callback noticies that the
> breakpoint is of its interest and sets the instruction
> pointer to SSOL area and requests UTRACE_SINGLESTEP. It
> also shows interest in quiesce event and the quiesce
> handler returns UTRACE_SINGLESTEP if the singlestep
> operation is not complete.
>
>
> D. Since UTRACE_STOP is preferred over UTRACE_SINGLESTEP, the
> traced program ("ls") is stopped and gdb prompt comes up.
> with the message"
"Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000110020 in ?? () "
>
> 4. continue at gdb prompt
> A. uprobe_report_quiesce doesn't get called
> B. does a resume and not a singlestep.
> C. Can result in SIGSEGV/SIGILL.
> D. report_signal callback for both engines run but for a
> different signal.
> I. gdb engine sets UTRACE_STOP.
> II. uprobe engines set UTRACE_RESUME as it is in a
> different event (not a breakpoint or singlestep event).
> E. uprobes cannot complete singlestep and hence cannot change
> the instruction pointer to the main instruction stream.
> F. traced program is stopped and gdb prompt comes up with
> message " ".
Program received signal SIGSEGV, Segmentation fault.
0x0000000000111000 in ?? ()
>
> 5. repeat step 4.
> A. Same as in Step 4.
> B. process is in UTRACE_STOP hence has to be SIGKILLED.
>
However if we use ni instead of continue at step 4 and then use
continue at step 5, the traced process runs to completion without any
issues.
It looks like on the latest utrace code, utrace and ptrace on the same
task is disabled.
--
Thanks and Regards
Srikar
