Bug 14236 - Cannot continue in background with target-async after interrupting
Summary: Cannot continue in background with target-async after interrupting
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.4
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-06-14 16:31 UTC by Mak Nazečić-Andrlon
Modified: 2014-07-12 21:40 UTC (History)
3 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Mak Nazečić-Andrlon 2012-06-14 16:31:11 UTC
When using target-async, continuing immediately after interrupting fails. I discovered this while experimenting with the Python API. time.sleep()ing for any amount of time doesn't fix the problem.

Using gdb 7.4.1 on Arch Linux.

Example session exhibiting the bug (yes, it looked exactly like that):

(gdb) define buggy
Type commands for definition of "buggy".
End with a line saying just "end".
>continue &
>continue &
(gdb) buggy
Cannot execute this command while the selected thread is running.
Program received signal SIGINT, Interrupt.
0x00007fc11e5fbb5d in nanosleep () from /lib/libc.so.6
Comment 1 dje 2014-03-22 00:05:15 UTC
I believe what's going on here is that the "interrupt" command is either designed wrong or implemented wrong.

There is an implicit "&" in "interrupt".
IOW, you typed "interrupt" but gdb interprets it as "interrupt &".
IOW, "interrupt" is just a request to stop a thread, it doesn't actually wait for the thread to stop.
Thus the subsequent "continue &" command is done before the thread has stopped, hence the error.

I agree there's a bug here somewhere.
An implicit "&" is confusing, thus IMO that's at least one bug.
A request to stop a thread should be "interrupt &".
"interrupt" by itself should wait until the thread has stopped.
Comment 2 dje 2014-03-23 23:40:08 UTC
Testing patch.
Comment 3 Doug Evans 2014-03-30 21:03:00 UTC
Now that I have a patch that works (from a user's perspective) the way I want it to, I've found three testcases that assume an implicit "&":


Another way to look at this, obviously, is to not expect the "interrupt" command to wait, and have a separate "wait" command.  I think we want a separate wait command, regardless. However, that doesn't mean the current design of interrupt isn't broken.
Alas, adding "&" to "interrupt", and changing the default behaviour to wait, *could* break existing code.

Another way to do is to add a "-w" command to interrupt to mean "wait".
All that would mean is that one could type

interrupt -a -w

instead of

interrupt -a
wait -a

The latter, however, opens up a source of confusion if the user types

interrupt -a

With my user's hat on I'd expect that when I see the gdb prompt after doing "interrupt -a" all threads are in fact stopped.  I'm working on the above alternatives, but for now I'm going to see what the community thinks of adding & to "interrupt".