Re: gdb fails to flush output (msys2)

["Juan José García-Ripoll" <juanjose.garciaripoll@gmail.com>]

I am not sure this has to do with using spawn() which IMHO would also
benefit Windows as compared to faking fork(). To confirm this, I have
run emacs and gdb inside Process Explorer. Just before I enter "run" in
the "gdb" window, Process Explorer shows a total of 30kb written by gdb,
while after my process is finished it shows 32kb. Those extra 2kb are
not shown by Emacs.

Below I show a complete interaction consisting on four steps: (1) launch
gdb with M-x gdb, supplying "c:/msys64/ucrt64/bin/gdb -i=mi
c:/home/juanjo/src/tensor/build-msys2-ucrt64/tests/test_rand.exe", (2)
enter "run" + enter in gdb, (3) press again <enter>, (4) press <enter>,
(5) type "quit" follwed by <enter>. Note how Emacs fails to show me the
output of the debugger and interprets a single <enter> as pressing "run"
again. Between steps (1) and (2), Process Explorer shows 2k of written
data, after (3) it shows another 2k.

Current directory is c:/home/juanjo/src/tensor/build-msys2-ucrt64/tests/
GNU gdb (GDB) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from c:/home/juanjo/src/tensor/build-msys2-ucrt64/tests/test_rand.exe...
(gdb) run <<<< Step (2)
Starting program: c:\home\juanjo\src\tensor\build-msys2-ucrt64\tests\test_rand.exe 
[New Thread 17312.0x144c]
[New Thread 17312.0x1f28]
[New Thread 17312.0x4d0]
<<< Step (3), press <enter>
[[----------] Global test environment set-up.
[----------] 10 tests from RandTest
[ RUN      ] RandTest.IntSize
[       OK ] RandTest.IntSize (0 ms)
[ RUN      ] RandTest.LongSize
[       OK ] RandTest.LongSize (0 ms)
[ RUN      ] RandTest.Reseed
[       OK ] RandTest.Reseed (1 ms)
[ RUN      ] RandTest.DoubleBalanced
[       OK ] RandTest.DoubleBalanced (0 ms)
[ RUN      ] RandTest.DoubleSigma
[       OK ] RandTest.DoubleSigma (1 ms)
[ RUN      ] RandTest.ComplexBalanced
[       OK ] RandTest.ComplexBalanced (1 ms)
[ RUN      ] RandTest.ComplexUncorrelated
[       OK ] RandTest.ComplexUncorrelated (0 ms)
[ RUN      ] RandTest.IntEmpty
[       OK ] RandTest.IntEmpty (0 ms)
[ RUN      ] RandTest.LongEmpty
[       OK ] RandTest.LongEmpty (0 ms)
[ RUN      ] RandTest.ULongEmpty
[       OK ] RandTest.ULongEmpty (0 ms)
[----------] 10 tests from RandTest (3 ms total)

[----------] Global test environment tear-down
[[  PASSED  ] 10 tests.
[Thread 17312.0x1f28 exited with code 0]
[Thread 17312.0x4d0 exited with code 0]
[Thread 17312.0x144c exited with code 0]
[Inferior 1 (process 17312) exited normally]
(gdb) Starting program: c:\home\juanjo\src\tensor\build-msys2-ucrt64\tests\test_rand.exe 
[New Thread 18700.0xdf8]
[New Thread 18700.0x18f4]
[New Thread 18700.0xf08]
[<<< Step (4), press <enter>
[----------] Global test environment set-up.
[----------] 10 tests from RandTest
[ RUN      ] RandTest.IntSize
[       OK ] RandTest.IntSize (0 ms)
[ RUN      ] RandTest.LongSize
[       OK ] RandTest.LongSize (0 ms)
[ RUN      ] RandTest.Reseed
[       OK ] RandTest.Reseed (1 ms)
[ RUN      ] RandTest.DoubleBalanced
[       OK ] RandTest.DoubleBalanced (0 ms)
[ RUN      ] RandTest.DoubleSigma
[       OK ] RandTest.DoubleSigma (2 ms)
[ RUN      ] RandTest.ComplexBalanced
[       OK ] RandTest.ComplexBalanced (0 ms)
[ RUN      ] RandTest.ComplexUncorrelated
[       OK ] RandTest.ComplexUncorrelated (1 ms)
[ RUN      ] RandTest.IntEmpty
[       OK ] RandTest.IntEmpty (0 ms)
[ RUN      ] RandTest.LongEmpty
[       OK ] RandTest.LongEmpty (0 ms)
[ RUN      ] RandTest.ULongEmpty
[       OK ] RandTest.ULongEmpty (0 ms)
[----------] 10 tests from RandTest (4 ms total)

[----------] Global test environment tear-down
[[  PASSED  ] 10 tests.
[Thread 18700.0xf08 exited with code 0]
[Thread 18700.0xdf8 exited with code 0]
[Thread 18700.0x18f4 exited with code 0]
[Inferior 1 (process 18700) exited normally]
(gdb) Starting program: c:\home\juanjo\src\tensor\build-msys2-ucrt64\tests\test_rand.exe 
[New Thread 12752.0x21b4]
[New Thread 12752.0x3710]
[New Thread 12752.0x4934]
[quit<<< Step (4)

Debugger finished


Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> 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

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es