[Bug mi/29002] New: Console input broken in MI mode

[Bug mi/29002] New: Console input broken in MI mode

[eliz at gnu dot org]

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

            Bug ID: 29002
           Summary: Console input broken in MI mode
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mi
          Assignee: unassigned at sourceware dot org
          Reporter: eliz at gnu dot org
  Target Milestone: ---

In the GDB-12.0.90 pretest built with mingw.org's MinGW as 32-bit MS-Windows
program, console input in MI mode is badly broken:

  (gdb)
  r -Q
  &"g\n"
  &"Ambiguous command \"g\": gcore, generate-core-file, goto-bookmark, gr, gu,
guile, guile-repl.\n"
  ^error,msg="Ambiguous command \"g\": gcore, generate-core-file,
goto-bookmark, gr, gu, guile, guile-repl."

As can be seen, no matter what I type, GDB thinks I typed "g\n", and reacts
accordingly.  This means I cannot even quit GDB normally, only kill it.

There's no such problems using the CLI interpreter, only when invoking GDB with
the -i=mi switch.

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

[Bug mi/29002] Console input broken in MI mode

[eliz at gnu dot org]

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

Eli Zaretskii <eliz at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.1
             Target|                            |i686-pc-mingw32
               Host|                            |i686-pc-mingw32
              Build|                            |i686-pc-mingw32

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

[Bug mi/29002] Console input broken in MI mode

[eliz at gnu dot org]

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

--- Comment #1 from Eli Zaretskii <eliz at gnu dot org> ---
Created attachment 14037
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14037&action=edit
Provisional patch to solve the broken console input in MI mode

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

[Bug mi/29002] Console input broken in MI mode

[eliz at gnu dot org]

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

--- Comment #2 from Eli Zaretskii <eliz at gnu dot org> ---
The culprit is this commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Author:     Andrew Burgess <aburgess@redhat.com>
  AuthorDate: Wed Dec 22 12:57:44 2021 +0000
  Commit:     Andrew Burgess <aburgess@redhat.com>
  CommitDate: Mon Feb 7 10:24:27 2022 +0000

      gdb: unbuffer all input streams when not using readline

I guess the detailed analysis in that commit, which describes the behavior of
glibc and the Linux kernel, doesn't fully apply to MS-Windows and its C
runtime...

The patch I proposed, which partially reverts that commit, fixes the issue for
me on MS-Windows.  But if we want to keep the current code for GNU/Linux and
other platforms, I guess the actual fix will need to be more complex.

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

[Bug mi/29002] Console input broken in MI mode

[eliz at gnu dot org]

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

--- Comment #3 from Eli Zaretskii <eliz at gnu dot org> ---
But this is not the whole story.  That commit also causes the Emacs gdb-mi
front-end to GDB to become broken, at least on MS-Windows.

What happens is that gdb-mi sends, via the GDB/MI interface, several commands
in a sequence when the debugging session begins.  Those commands are:

  1-gdb-set new-console off
  2-gdb-set interactive-mode on
  3-gdb-set height 0
  4-enable-pretty-printing
  5-enable-frame-filters
  6-file-list-exec-source-file
  7-gdb-show prompt
  8-stack-info-frame
  9-thread-info
  10-break-list
  11-thread-info
  12-break-list

But when GDB responds to those commands, some of the responses have the first
character of the TOKEN part stripped.  Here's what Emacs receives in response
(this is a single string sent to Emacs in one go):

1^done
(gdb) 
2^done
(gdb) 
3^done
(gdb) 
^done
(gdb) 
5^done
(gdb) 
^done,line=\"1189\",file=\"emacs.c\",fullname=\"d:\\\\gnu\\\\git\\\\emacs\\\\branch\\\\src\\\\emacs.c\",macro-info=\"1\"
(gdb) 
7^done,value=\"(gdb) \"
(gdb) 
8^error,msg=\"No registers.\"
(gdb) 
^done,threads=[]
(gdb) 
0^done,BreakpointTable={nr_rows=\"1\",nr_cols=\"6\",hdr=[{width=\"7\",alignment=\"-1\",col_name=\"number\",colhdr=\"Num\"},{width=\"14\",alignment=\"-1\",col_name=\"type\",colhdr=\"Type\"},{width=\"4\",alignment=\"-1\",col_name=\"disp\",colhdr=\"Disp\"},{width=\"3\",alignment=\"-1\",col_name=\"enabled\",colhdr=\"Enb\"},{width=\"10\",alignment=\"-1\",col_name=\"addr\",colhdr=\"Address\"},{width=\"40\",alignment=\"2\",col_name=\"what\",colhdr=\"What\"}],body=[bkpt={number=\"1\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"0x0115dc0c\",func=\"terminate_due_to_signal\",file=\"emacs.c\",fullname=\"d:\\\\gnu\\\\git\\\\emacs\\\\branch\\\\src\\\\emacs.c\",line=\"400\",thread-groups=[\"i1\"],times=\"0\",original-location=\"terminate_due_to_signal\"}]}
(gdb) 
1^done,threads=[]
(gdb) 
12^done,BreakpointTable={nr_rows=\"1\",nr_cols=\"6\",hdr=[{width=\"7\",alignment=\"-1\",col_name=\"number\",colhdr=\"Num\"},{width=\"14\",alignment=\"-1\",col_name=\"type\",colhdr=\"Type\"},{width=\"4\",alignment=\"-1\",col_name=\"disp\",colhdr=\"Disp\"},{width=\"3\",alignment=\"-1\",col_name=\"enabled\",colhdr=\"Enb\"},{width=\"10\",alignment=\"-1\",col_name=\"addr\",colhdr=\"Address\"},{width=\"40\",alignment=\"2\",col_name=\"what\",colhdr=\"What\"}],body=[bkpt={number=\"1\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"0x0115dc0c\",func=\"terminate_due_to_signal\",file=\"emacs.c\",fullname=\"d:\\\\gnu\\\\git\\\\emacs\\\\branch\\\\src\\\\emacs.c\",line=\"400\",thread-groups=[\"i1\"],times=\"0\",original-location=\"terminate_due_to_signal\"}]}

Note that responses to 4, 6, and 9 don't have the TOKEN part, and responses to
10 and 11 have the first digit, 1, removed from TOKEN, so they appear as if the
TOKEN were 0 (which is invalid) and 1 (which was already received, and so is
not expected at this time).

It turns out that restoring the "done_once" part of the offending commit fixes
this problem as well.  I'm guessing that the repeated calls to `setbuf` cause
those characters to be lost, perhaps because `setbuf` flushes the stream, which
for an input stream means it empties the buffer.  And we do call `setbuf` in
this scenario, because interaction between Emacs and GDB in this case is via
pipes.

In general, AFAIK the C standard allows to call `setvbuf` (and thus `setbuf`)
only once, before any I/O operation was done for a given stream.  But after the
commit mentioned above, we call `setbuf` multiple times.

So the proposed patch now changes to an almost full revert of the offending
commit, see the attachment.

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

[Bug mi/29002] Console input broken in MI mode

[eliz at gnu dot org]

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

--- Comment #4 from Eli Zaretskii <eliz at gnu dot org> ---
Created attachment 14039
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14039&action=edit
More thorough patch to fix the gdb-mi problem as well

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

[Bug mi/29002] Console input broken in MI mode

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joel Brobecker <brobecke@sourceware.org>:

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

commit ac16b09d7e5fd0013ffa27e4d0531c0af12a529a
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Sun Apr 24 08:39:19 2022 -0700

    gdb: move setbuf calls out of gdb_readline_no_editing_callback

    After this commit:

      commit d08cbc5d3203118da5583296e49273cf82378042
      Date:   Wed Dec 22 12:57:44 2021 +0000

          gdb: unbuffer all input streams when not using readline

    Issues were reported with some MS-Windows hosts, see the thread
    starting here:

      https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html

    Filed in bugzilla as: PR mi/29002

    The problem seems to be that calling setbuf on terminal file handles
    is not always acceptable, see this mail for more details:

      https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html

    This commit does two things, first moving the setbuf calls out of
    gdb_readline_no_editing_callback so that we don't end up calling
    setbuf so often.

    Then, for MS-Windows hosts, we don't call setbuf for terminals, this
    appears to resolve the issues that have been reported.

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

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

[Bug mi/29002] Console input broken in MI mode

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-12-branch branch has been updated by Joel Brobecker
<brobecke@sourceware.org>:

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

commit e312dfbe9556d8e4557abe7fd3f1a4681e15da06
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Sun Apr 24 08:39:19 2022 -0700

    gdb: move setbuf calls out of gdb_readline_no_editing_callback

    After this commit:

      commit d08cbc5d3203118da5583296e49273cf82378042
      Date:   Wed Dec 22 12:57:44 2021 +0000

          gdb: unbuffer all input streams when not using readline

    Issues were reported with some MS-Windows hosts, see the thread
    starting here:

      https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html

    Filed in bugzilla as: PR mi/29002

    The problem seems to be that calling setbuf on terminal file handles
    is not always acceptable, see this mail for more details:

      https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html

    This commit does two things, first moving the setbuf calls out of
    gdb_readline_no_editing_callback so that we don't end up calling
    setbuf so often.

    Then, for MS-Windows hosts, we don't call setbuf for terminals, this
    appears to resolve the issues that have been reported.

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

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

[Bug mi/29002] Console input broken in MI mode

[brobecker at gnat dot com]

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

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Assignee|unassigned at sourceware dot org   |aburgess at redhat dot com
         Resolution|---                         |FIXED
                 CC|                            |brobecker at gnat dot com

--- Comment #7 from Joel Brobecker <brobecker at gnat dot com> ---
Andrew's patch now pushed to both master and gdb-12.

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

[Bug mi/29002] Console input broken in MI mode

[equationssolver at yahoo dot com]

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

hmb <equationssolver at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |equationssolver at yahoo dot com

--- Comment #8 from hmb <equationssolver at yahoo dot com> ---
I'm still encountering an error with the latest 13.2 release of GDB on a
Windows host. When using GDB, I'm not receiving responses for the MI commands,
causing my IDE (Eclipse) to freeze and become unresponsive.

To reproduce the issue, I have the following scenario in PowerShell:

$  cat input
1-list-thread-groups
2-list-thread-groups
3-list-thread-groups

cat input | arm-none-eabi-gdb.exe --silent --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
1^done,groups=[{id="i1",type="process"}]
(gdb)
&"warning: Exception condition detected on fd 0\n"
&"error detected on stdin\n"



As observed, there is no response for the MI commands numbered 2 and 3."

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

[Bug mi/29002] Console input broken in MI mode

[equationssolver at yahoo dot com]

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

--- Comment #9 from hmb <equationssolver at yahoo dot com> ---
reported https://sourceware.org/bugzilla/show_bug.cgi?id=30627

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

[Bug mi/29002] Console input broken in MI mode

[eliz at gnu dot org]

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

--- Comment #10 from Eli Zaretskii <eliz at gnu dot org> ---
(In reply to hmb from comment #8)
> I'm still encountering an error with the latest 13.2 release of GDB on a
> Windows host. When using GDB, I'm not receiving responses for the MI
> commands, causing my IDE (Eclipse) to freeze and become unresponsive.
> 
> To reproduce the issue, I have the following scenario in PowerShell:
> 
> $  cat input
> 1-list-thread-groups
> 2-list-thread-groups
> 3-list-thread-groups
> 
> cat input | arm-none-eabi-gdb.exe --silent --interpreter=mi2
> =thread-group-added,id="i1"
> (gdb)
> 1^done,groups=[{id="i1",type="process"}]
> (gdb)
> &"warning: Exception condition detected on fd 0\n"
> &"error detected on stdin\n"
> 
> 
> 
> As observed, there is no response for the MI commands numbered 2 and 3."

I cannot reproduce this with GDB 13.1 I built myself with mingw.org's MinGW. 
For the same input, but using the native MS-Windows GDB, I get this:

d:\usr>cat gdb.input | gdb  --silent --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
1^done,groups=[{id="i1",type="process"}]
(gdb)
2^done,groups=[{id="i1",type="process"}]
(gdb)
3^done,groups=[{id="i1",type="process"}]
(gdb)
&"warning: Exception condition detected on fd 0\n"
&"error detected on stdin\n"

So all the 3 commands were processed.

In case it's important, I ran this command from cmd.exe, not from PowerShell.

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

[Bug mi/29002] Console input broken in MI mode

[equationssolver at yahoo dot com]

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

--- Comment #11 from hmb <equationssolver at yahoo dot com> ---
Upon further investigation, I have determined that the issue reported in this
bug is not related to the upstream GDB project. The problem actually resides in
our local patch or configuration.

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