Re: gdb fails to flush output (msys2)

[Jostein Kjønigsen]

On 15.03.2022 10:58, Juan José García-Ripoll wrote:

Eli Zaretskii <eliz@gnu.org> writes:

Can you show how that program behaves when invoked from the system
shell, not under the debugger?  Also, if you invoke "M-x shell" inside
Emacs, and then run that program from the inferior shell, does it
behave correctly, or does it also hangs until you type Enter?

Let me summarize all the questions in this single post. What is related
to MSYS2 is the use of MSYS2's toolchains for building and debugging the
software. There is nothing specific to MSYS2 other than specifying to
Emacs that the debugger is c:/msys64/ucrt64/bin/gdb.exe or some other
program from the toolchain I choose.

Your paragraph abore is quite on spot. As I stated before, if I use M-x
shell and invoke the debugger from the shell (still within Emacs)
everything works just fine, so it is not a buffering issue. Also, to be
more precise, within the debugger the program runs to completion, which
means the output is completely unbuffered. It therefore should have been
shown by Emacs' gdb already when I copied the text.

Another indication that there is some problem with Emacs' GDB/GUD
packages is that the output _is_ there. If I type a command right after
the last shown output, gdb executes that command, and any following one,
but re-displays the original output of the program again and again. It
is somehow as if it had reinterpreted the program's output as a prompt.

Is there a way I can debug how GUD is behaving or interfacing with gdb's
output? I know some other major modes keep debugging information or
intermediate buffers if requested. But I still have not found it for
GUD.

Best,

Could this error in any way be related to the previous issue with had with "use posix_spawn"? [1]

For those who need a reminder, as far as I understood it, the key issue there was that  a required bugfix for Mac (but also generally an optimization) was made into a default optimization for platforms, and the idea was that unless it was proven troublesome one could decide to keep it.

Well, on Linux it did cause some issues with triggering external processes. Specifically .NET-based tooling, made especially painful with .NET-based Language Server implementations no longer working (C# and F#).

If this is another instance of such a bug (and I'm deliberately qualifing that with an "if"), would it make sense to reverse this optimization on all platforms not Mac? There seems to be several unintended side-effects, and could possibly be more?

[1] https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01561.html

--
Kind regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no