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 & >interrupt >continue & >end (gdb) buggy Cannot execute this command while the selected thread is running. (gdb) Program received signal SIGINT, Interrupt. 0x00007fc11e5fbb5d in nanosleep () from /lib/libc.so.6
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.
Testing patch.
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 "&": gdb.base/ async-shell.exp dprintf-non-stop.exp interrupt-noterm.exp 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 wait 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".
Current set of patches: https://sourceware.org/ml/gdb-patches/2014-07/msg00304.html https://sourceware.org/ml/gdb-patches/2014-07/msg00305.html