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 "
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 " ".
5. repeat step 4.
A. Same as in Step 4.
B. process is in UTRACE_STOP hence has to be SIGKILLED.
--
Thanks and Regards
Srikar
