Bug 23820

Summary:	No one handle "current_ui->prompt_state = PROMPT_NEEDED"
Product:	gdb	Reporter:	jiangshuaili <lijiang1489>
Component:	mi	Assignee:	Tom Tromey <tromey>
Status:	RESOLVED FIXED
Severity:	normal	CC:	tromey
Priority:	P2
Version:	8.2
Target Milestone:	12.1
Host:		Target:
Build:		Last reconfirmed:	2022-02-24 00:00:00

Description jiangshuaili 2018-10-25 07:01:34 UTC

There is a case that when debugging a program using gdb mi， if a command  got an error and throw_error back to function"start_event_loop", the error message has been displayed, but prompt "(gdb)" is not displayed.

Actually, command line can get input now，"(gdb)" is displayed when the next command done. But this state is not right, some IDEs can not get the state of program now.

A way to reproducing this case：
resources:
1. an a.out with debug-info
2. a gdb_debug with debug-info
3. a gdbserver
4. a gdb

step:
1. run gdbserver :112233 a.out
2. gdb --args ./gdb_debug a.out --inter mi
   b remote_wait (or remote_target::wait)
   run
3. come to gdb_debug:
   tar rem:112233
4. come to gdb:
   continue
5. come to gdb_debug:
   singlestep
6. come to gdb:
   b readchar (or remote_target::readchar)
   continue
7. ps -A | grep gdbserver
   kill -9 pid_of_gdbserver
8. come to gdb:
   break event-loop.c:380 (380 for gdb8.2, in function "start_event_loop", after "CATCH" operation, where function async_enable_stdin() wrote.)
   continue

Result:
when gdb_debug back to "start_event_loop, event-loop.c:380", you can remove all breakpoints, and come to gdb doing continue:
At this time, connection for gdbserver is lost, gdb_debug print the correspond message too, but prompt "(gdb)" is not outputed event if “current_ui->prompt_state = PROMPT_NEEDED” has been written in function “start_event_loop”.

Comment 1 Tom Tromey 2022-02-24 16:46:09 UTC

I ran across this as well.
I sent this patch, but no comments yet
https://sourceware.org/pipermail/gdb-patches/2022-January/184881.html

Comment 2 Sourceware Commits 2022-02-25 14:32: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=e8b4efc3cf3d5d2c475b3e5c31439aa5bcd277ae

commit e8b4efc3cf3d5d2c475b3e5c31439aa5bcd277ae
Author: Tom Tromey <tromey@adacore.com>
Date:   Thu Jan 6 08:42:49 2022 -0700

    Print MI prompt on interrupted command
    
    Joel noticed that if the remote dies unexpectedly during a command --
    you can simulate this by using "continue" and then killing gdbserver
    -- then the CLI will print a new prompt, but MI will not.  Later, we
    found out that this was also filed in bugzilla as PR mi/23820.
    
    The output looks something like this:
    
        | (gdb)
        | cont
        | &"cont\n"
        | ~"Continuing.\n"
        | ^running
        | *running,thread-id="all"
        | (gdb)
        | [... some output from GDB during program startup...]
        | =thread-exited,id="1",group-id="i1"
        | =thread-group-exited,id="i1"
        | &"Remote connection closed\n"
    
    Now, what about that "(gdb)" in the middle?
    
    That prompt comes from this questionable code in
    mi-interp.c:mi_on_resume_1:
    
          /* This is what gdb used to do historically -- printing prompt
             even if it cannot actually accept any input.  This will be
             surely removed for MI3, and may be removed even earlier.  */
          if (current_ui->prompt_state == PROMPT_BLOCKED)
            fputs_unfiltered ("(gdb) \n", mi->raw_stdout);
    
    ... which seems like something to remove.  But maybe the intent here
    is that this prompt is sufficient, and MI clients must be ready to
    handle output coming after a prompt.  On the other hand, if this code
    *is* removed, then nothing would print a prompt in this scenario.
    
    Anyway, the CLI and the TUI handle emitting the prompt here by hooking
    into gdb::observers::command_error, but MI doesn't install an observer
    here.
    
    This patch adds the missing observer and arranges to show the MI
    prompt.  Regression tested on x86-64 Fedora 34.
    
    It seems like this area could be improved a bit, by having
    start_event_loop call the prompt-displaying code directly, rather than
    indirecting through an observer.  However, I haven't done this.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820

Comment 3 Tom Tromey 2022-02-25 14:33:10 UTC

Fixed.