[Bug gdb/14236] New: Cannot continue in background with target-async after interrupting

[Bug gdb/14236] New: Cannot continue in background with target-async after interrupting

[owlberteinstein at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14236

             Bug #: 14236
           Summary: Cannot continue in background with target-async after
                    interrupting
           Product: gdb
           Version: 7.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: owlberteinstein@gmail.com
    Classification: Unclassified


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

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14236] Cannot continue in background with target-async after interrupting

[owlberteinstein at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14236

Mak Nazečić-Andrlon <owlberteinstein at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |owlberteinstein at gmail
                   |                            |dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14236] Cannot continue in background with target-async after interrupting

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14236

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at google dot com

--- Comment #1 from dje at google dot com ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14236] Cannot continue in background with target-async after interrupting

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14236

--- Comment #2 from dje at google dot com ---
Testing patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14236] Cannot continue in background with target-async after interrupting

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14236

Doug Evans <xdje42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdje42 at gmail dot com

--- Comment #3 from Doug Evans <xdje42 at gmail dot com> ---
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".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14236] Cannot continue in background with target-async after interrupting

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14236

--- Comment #4 from Doug Evans <xdje42 at gmail dot com> ---
Current set of patches:
https://sourceware.org/ml/gdb-patches/2014-07/msg00304.html
https://sourceware.org/ml/gdb-patches/2014-07/msg00305.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.