gdb: clear proceed status before starting a new inferior
This patch fixes a bug when 'set schedule-multiple on' is in use and a
second inferior is started using the 'run' command (or 'start' or
'starti'). This bug was reported as PR gdb/28777.
The problem appears as the first inferior terminating with an
unexpected SIGTRAP. The bug can be reproduced like this:
gdb -ex 'set schedule-multiple on' \
-ex 'file /tmp/spin' \
-ex 'break main' \
-ex 'run' \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file /tmp/spin' \
-ex 'break main' \
-ex 'run'
The final 'run' can be replaced with 'start' or 'starti'. The output
is different in the 'starti' case, but the cause is the same. For the
'run' and 'start' cases the final output is:
Starting program: /tmp/spin
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
In the 'starti' case the output is:
Starting program: /tmp/spin
Thread 2.1 "spin" stopped.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
What's happening is that GDB is failing to clear the previous proceed
status from inferior 1 before starting inferior 2. Normally when
schedule-multiple is off, this isn't a problem as 'run' only starts
the new inferior, and the new inferior will have no previous proceed
status that needs clearing.
But when schedule-multiple is on, starting a new inferior, with 'run'
and friends, will actually start all inferiors, including those that
previous stopped at a breakpoint with a SIGTRAP signal.
By failing to clear out the proceed status for those threads, when GDB
restarts inferior 1 it arranges for the thread to receive the SIGTRAP,
which is delivered, and, as GDB isn't expecting a SIGTRAP, is allowed
to kill the process.
Fix this by calling clear_proceed_status from run_command_1.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28777
2 files changed
