(Windows) Problems with processes on master branch

(Windows) Problems with processes on master branch

[Óscar Fuentes]

With a fresh MSYS2/Mingw-w64 build executed on Windows 11 64bits with
-Q, emacs mangles the output of processes and does not detect when they
end.

For instance, with emacs -Q

M-x shell

it shows

icrosoft Windows [Version <omitted rest of output>

Note the missing initial M. Then, emacs hangs (no input possible, C-g
doen't work) showing (Shell:run) on the modeline.

If I execute eshell instead of shell and invoke an executable like

$ gcc -v

the shown output misses the first line:

Using built-in specs.

and then eshell keeps waiting as if the command would still be
executing, which is false (Windows' Task Manager confirms that there is
no gcc executable running).

Is this a known problem?

Re: (Windows) Problems with processes on master branch

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 01 Mar 2024 17:46:10 +0100
> 
> With a fresh MSYS2/Mingw-w64 build executed on Windows 11 64bits with
> -Q, emacs mangles the output of processes and does not detect when they
> end.
> 
> For instance, with emacs -Q
> 
> M-x shell
> 
> it shows
> 
> icrosoft Windows [Version <omitted rest of output>
> 
> Note the missing initial M. Then, emacs hangs (no input possible, C-g
> doen't work) showing (Shell:run) on the modeline.

I cannot reproduce this with the latest master branch.  My build is a
32-bit one, but I don't think it should matter.

> If I execute eshell instead of shell and invoke an executable like
> 
> $ gcc -v
> 
> the shown output misses the first line:
> 
> Using built-in specs.
> 
> and then eshell keeps waiting as if the command would still be
> executing, which is false (Windows' Task Manager confirms that there is
> no gcc executable running).

I cannot reproduce this, either.

My first guess would be some weird buffering issue.  But I have no
clue why it would happen.  Which versions of Emacs behave like that?

Re: (Windows) Problems with processes on master branch

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> My first guess would be some weird buffering issue.  But I have no
> clue why it would happen.  Which versions of Emacs behave like that?

This is current master branch.

I vaguely recall experiencing the same problem long time ago. Indeed it
looks like a buffering problem, probably on the mingw-64 runtime side,
that's why I didn't report an Emacs bug. However, the emacs-29
msys2/mingw-w64 package works fine.

Thanks.

Re: (Windows) Problems with processes on master branch

[Corwin Brust]

FWIW, I cannot reproduce truncation of the initial output from M-x
shell with a self-built 31a4bec609578afd453caf232f78e275c3a075bc (only
a few commits behind HEAD, I believe).

This looks fine:

Microsoft Windows [Version 10.0.19045.4123]
(c) Microsoft Corporation. All rights reserved.

C:\>

Re: (Windows) Problems with processes on master branch

[Arash Esbati]

Óscar Fuentes <ofv@wanadoo.es> writes:

> With a fresh MSYS2/Mingw-w64 build executed on Windows 11 64bits with
> -Q, emacs mangles the output of processes and does not detect when they
> end.
>
> For instance, with emacs -Q
>
> M-x shell
>
> it shows
>
> icrosoft Windows [Version <omitted rest of output>
>
> Note the missing initial M. Then, emacs hangs (no input possible, C-g
> doen't work) showing (Shell:run) on the modeline.

With my Emacs 30 (d0766c0999) build, started from cmd.exe with
'runemacs -Q' and M-x shell RET, I get:

--8<---------------cut here---------------start------------->8---
Microsoft Windows [Version 10.0.19045.4046]
(c) Microsoft Corporation. Alle Rechte vorbehalten.

z:dir\>gcc -v
gcc -v
Using built-in specs.
...
--8<---------------cut here---------------end--------------->8---

With 'emacs -Q' started from a MinGW64 shell, M-x shell RET says:

--8<---------------cut here---------------start------------->8---
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

$ gcc -v
Using built-in specs.
...
--8<---------------cut here---------------end--------------->8---

Both versions work, despite the bash message.  I didn't try eshell.

Best, Arash

Re: (Windows) Problems with processes on master branch

[Óscar Fuentes]

Arash Esbati <arash@gnu.org> writes:

> With my Emacs 30 (d0766c0999) build, started from cmd.exe with
> 'runemacs -Q' and M-x shell RET, I get:
>
> Microsoft Windows [Version 10.0.19045.4046]
> (c) Microsoft Corporation. Alle Rechte vorbehalten.
>
> z:dir\>gcc -v
> gcc -v
> Using built-in specs.
> ...
>
>
> With 'emacs -Q' started from a MinGW64 shell, M-x shell RET says:
>
> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
> bash: no job control in this shell
>
> $ gcc -v
> Using built-in specs.
> ...
>
> Both versions work, despite the bash message.  I didn't try eshell.

Thanks Arash and Corwin.

The problem is caused by MSYS2 makepkg-mingw (the MSYS2 binary package
builder) which adds

-D_FORTIFY_SOURCE

to CFLAGS. In fact, the MSYS2/Mingw-packages recipe for emacs-29
contains:

  # -D_FORTIFY_SOURCE breaks build
  CFLAGS=${CFLAGS//"-Wp,-D_FORTIFY_SOURCE=2"}
  # -foptimize-sibling-calls breaks native compilation (GCC 13.1)
  CFLAGS+=" -fno-optimize-sibling-calls"

Once that is added to my recipe, the problem goes away.