Bug 30472 - DAP "repl" evaluation can make gdb unresponsive
Summary: DAP "repl" evaluation can make gdb unresponsive
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: dap (show other bugs)
Version: HEAD
: P2 enhancement
Target Milestone: 15.1
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-19 15:06 UTC by Tom Tromey
Modified: 2023-12-11 18:55 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2023-05-19 15:06:08 UTC
gdb implements the "repl" context for the "evaluate" request
by passing the string to gdb as a command.
However, if the command is something like "continue", gdb will
simply continue -- but the DAP thread will presumably wait,
because eval_request uses send_gdb_with_response.

At least... I think this should happen.  Step 1 would be to write
a test for this.  Then, if it fails, some solution would have to
be found.  Perhaps a global flag to automatically treat continue
commands as if they had a "&" would work.
Comment 1 Tom Tromey 2023-06-05 15:15:47 UTC
It occurs to me that this could also happen with the "target"
command, and for that one, "&" isn't implemented.
Comment 2 Tom Tromey 2023-06-05 15:40:15 UTC
See bug#7251.  Bug #7253 is also maybe relevant.

Maybe it would be enough to use send_gdb and then
have any output from the command be sent as output
events, not in the response.  Then the reader thread
could accept interrupt requests.
Comment 3 Tom Tromey 2023-07-27 19:43:59 UTC
Most of the problem could be solved by noticing when
the inferior continues and telling the DAP response that
it is done.
This wouldn't help with the "target" problem though.
Comment 4 Tom Tromey 2023-11-06 21:19:06 UTC
I realized somewhat belatedly that this problem also
affects evaluation of expressions that involve an
inferior call.  These can't be handled by changing
how the output is directed.
Comment 5 Tom Tromey 2023-11-06 21:20:25 UTC
I was thinking this could be handled by implementing cancellation,
but that will give weird results when used to interrupt an
inferior call.  Like, I suppose it would work, but the inferior
will be left in a somewhat weird state.

Also it seems a little strange to use cancellation to interrupt
a gdb CLI "continue" but not a DAP "continue".
Comment 6 Tom Tromey 2023-11-07 14:11:58 UTC
(In reply to Tom Tromey from comment #5)

> Also it seems a little strange to use cancellation to interrupt
> a gdb CLI "continue" but not a DAP "continue".

I go back and forth on this, but I suppose the difference is
that a repl evaluation of "continue" won't return a result,
so cancel would be correct.
Comment 7 Tom Tromey 2023-11-16 20:58:13 UTC
I'm working on this.
Comment 9 Sourceware Commits 2023-12-11 18:54:35 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1c79c8dad90e4382100b51694a2b9ee7e913a04a

commit 1c79c8dad90e4382100b51694a2b9ee7e913a04a
Author: Tom Tromey <tromey@adacore.com>
Date:   Tue Nov 7 10:56:07 2023 -0700

    Implement DAP cancellation
    
    This implements DAP cancellation.  A new object is introduced that
    handles the details of cancellation.  While cancellation is inherently
    racy, this code attempts to make it so that gdb doesn't inadvertently
    cancel the wrong request.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472
    Approved-By: Eli Zaretskii <eliz@gnu.org>
    Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Comment 10 Tom Tromey 2023-12-11 18:55:06 UTC
Fixed.