[1/1] gdb : Signal to pstack/gdb kills the attached process.
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
fail
|
Testing failed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-arm |
fail
|
Testing failed
|
Commit Message
From: Partha Sarathi Satapathy <partha.satapathy@oracle.com>
Problem::
While gdb attaching a target, If ctrl-c pressed in the midst of the
process attach, the sigint is passed to the debugged process. This
triggers exit of the debugged.
Let's take the example of pstack, which dumps the stack of all threads
in a process. In some cases printing of stack can take significant time
and ctrl-c is pressed to abort pstack/gdb application. This in turn
kills the debugged process, which can be critical for the system. In
this case the intention of "ctrl+c" to kill pstack/gdb, but not the
target application.
Reproduction:
The debugged application generally attached to process by:
gdb -p <<pid>>
or gdb /proc/<<pid>>/exe pid
pstack uses the latter method to attach the debugged to gdb. If the
application is large or process of reading symbols is slow, gives a good
window to press the ctrl+c during attach. Spawning "gdb" under "strace
-k" makes gdb a lot slower and gives a larger window to easily press the
ctrl+c at the precise period i.e. during the attach of the debugged
process. The above strace hack will enhance rate of reproduction of the
issue. Testcase:
With GDB 13.1
ps aux | grep abrtd
root 2195168 /usr/sbin/abrtd -d -s
Attaching to process 2195168
[New LWP 2195177]
[New LWP 2195179]
^C[Thread debugging using libthread_db enabled]
<<<< Note the ctrl+c is pressed after attach is initiated and it's
still reading the symbols from library >>>> Using host libthread_db
library "/lib64/libthread_db.so.1".
0x00007fe3ed6d70d1 in poll () from /lib64/libc.so.6
(gdb) q
A debugging session is active.
Inferior 1 [process 2195168] will be detached Quit anyway? (y
or n) y Detaching from program: /usr/sbin/abrtd, process 2195168
<<<< Process exited >>>>
Description:
We are installing a signal handler in gdb that marks the Ctrl-c/sigint
received by gdb. GDB passes this sigint to the debugged at some definite
points during the window of process attach. The process of attaching
debugged involves steps like PTRACE_ATTACH , reading symbols, getting
the stop signal from the debugged and get ready with GDB prompt. Note:
one of the example of this is sigint passing is:
" - installs a SIGINT handler that forwards SIGINT to the inferior.
Otherwise a Ctrl-C pressed just while waiting for the initial
stop would end up as a spurious Quit.
"
There are few other places where sigint is passed to the debugged during
attach of process to gdb. As the debugger and debugged are not fully
attached during this period, the sigint takes its default action and
terminates the process.
Solution:
While gdb attaches process, the target is not the current session
leader. Hence, until attach is complete and GDB prompt is availed, the
sigint should not be passed to the debugged. A similar approach is taken
for "gdb) run &". In target_terminal::inferior()
/* A background resume (``run&'') should leave GDB in control of the
terminal. */
if (ui->prompt_state != PROMPT_BLOCKED)
return;
The passing of signal is skipped if the process ran in background. With
this approach we can skip passing the sigint if the process is attached
to gdb and process attach is not complete.
Here is the proposed solution:
Fix :
While gdb attaching a target, If ctrl-c/sigint pressed in the midst of
the process attach, the sigint is passed to the debugged process.
This triggers exit of the debugged.
This issue is evident while getting the process stack with ./gdb
--quiet -nx -ex 'set width 0' -ex 'set height 0'
-ex 'set pagination no' -ex 'set confirm off'
-ex 'thread apply all bt' -ex quit /proc/<PID>/exe <PID> and press the
ctrl+c while attach.
The above method is also used in pstack application which is a wrapper
over gdb to print the process stack. A Ctrl+C intended to kill gdb or
pstack, but kills the debugged even if it is attached and not spawned by
gdb.
---
gdb/inferior.h | 3 +++
gdb/target.c | 4 ++++
gdb/top.c | 2 ++
3 files changed, 9 insertions(+)
@@ -557,6 +557,9 @@ class inferior : public refcounted_object,
/* True if this child process was attached rather than forked. */
bool attach_flag = false;
+ /* True if target process synced and gdb ui is out of block. */
+ bool sync_flag = false;
+
/* If this inferior is a vfork child, then this is the pointer to
its vfork parent, if GDB is still attached to it. */
inferior *vfork_parent = NULL;
@@ -3826,6 +3826,10 @@ struct target_ops *
through the target_stack. */
scoped_restore_current_inferior restore_inferior;
set_current_inferior (inf);
+ if ((current_inferior()->attach_flag) &&
+ !(current_inferior()->sync_flag)) {
+ return;
+ }
current_inferior ()->top_target ()->pass_ctrlc ();
return;
}
@@ -542,6 +542,8 @@ struct ui_out **
while (gdb_do_one_event () >= 0)
if (ui->prompt_state != PROMPT_BLOCKED)
break;
+
+ current_inferior()->sync_flag = true;
}
/* See top.h. */