Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wineserver -p && cl hangs forever #47

Closed
real-or-random opened this issue Mar 16, 2022 · 2 comments · Fixed by #65
Closed

wineserver -p && cl hangs forever #47

real-or-random opened this issue Mar 16, 2022 · 2 comments · Fixed by #65

Comments

@real-or-random
Copy link
Contributor

With my local installation, and with a self-create docker (I haven't tried the official docker):

When I run wineserver -p && cl it hangs forever without giving output.

The underlying issue seems to be that the stdin of the sed/grep pipeline is never disconnected. Even after the wine64 process is gone, the sed and grep procresses are still there and stay there forever. This is very strange, and I don't really how to debug this further but here are some observations:

  • In fact, there's output. It's just not printed due to a stdout/stderr buffering issue (and because stdin is never disconnected, the buffer is never flushed). I can get some output by changing the sed to sed -u or grep to grep --line-buffered.
  • Another way to get output is to run wineserver -k. Then the pipe is disconnected and the buffers are flushed.
  • Also interesting: wineserver -p3 && cl gives output after ~3 seconds (because then the wineserver dies). 3 seconds is the default when the wineserver is started automatically, and from time to time I had already noticed earlier that calling cl is very slow and essentially takes 3 seconds every time. This is probably the issue (even without invoking an explicit wineserver).
  • When removing the sed/grep pipeline, the problem just disappears entirely.
  • A reliable workaround is to run wineserver -p && wine foo && cl where foo is a (successful) dummy command, e.g. the builtin "hh.exe" is nice because it has no output".

I suspect that somehow the stdin of the pipe is connected to wineserver but I have no idea why this happens. The only thing I could find is this >20 years old thread about a similar issue https://marc.info/?l=wine-devel&m=96644429309991&w=2 But yeah, it's >20 years old...

@mstorsjo
Copy link
Owner

Yeah, when using a persistent wineserver, I'm running wine64 wineboot as a non-piped command to trigger it to start up, before running the actual compilation commands.

@real-or-random
Copy link
Contributor Author

Oh I was about to write that we should document it then but it's actually in the README (# Run wine at least once).

huangqinjin added a commit to huangqinjin/msvc-wine that referenced this issue Apr 27, 2023
A single wine invocation may spawn several long-living Win32 processes automatically.
These processes will inherit at least the stderr handle of current wine command and keep it open.
Waiting for the wine command's stderr will hang, e.g. CMake waits for the compilation commands:
https://gitlab.kitware.com/cmake/cmake/-/blob/0991023c30ed5b83bcb1446b5bcc9c1eae028835/Source/kwsys/ProcessUNIX.c#L1076

Fixes mstorsjo#47
huangqinjin added a commit to huangqinjin/msvc-wine that referenced this issue Apr 29, 2023
A single wine invocation may spawn several long-living Win32 processes automatically.
These processes will inherit at least the stderr handle of current wine command and keep it open.
Waiting for the wine command's stderr will hang, e.g. CMake waits for the compilation commands:
https://gitlab.kitware.com/cmake/cmake/-/blob/0991023c30ed5b83bcb1446b5bcc9c1eae028835/Source/kwsys/ProcessUNIX.c#L1076

Fixes mstorsjo#47
huangqinjin added a commit to huangqinjin/msvc-wine that referenced this issue May 3, 2023
A single wine invocation may spawn several long-living Win32 processes automatically.
These processes will inherit at least the stderr handle of current wine command and keep it open.
Waiting for the wine command's stderr will hang, e.g. CMake waits for the compilation commands:
https://gitlab.kitware.com/cmake/cmake/-/blob/0991023c30ed5b83bcb1446b5bcc9c1eae028835/Source/kwsys/ProcessUNIX.c#L1076

Fixes mstorsjo#47
mstorsjo pushed a commit that referenced this issue May 8, 2023
A single wine invocation may spawn several long-living Win32 processes automatically.
These processes will inherit at least the stderr handle of current wine command and keep it open.
Waiting for the wine command's stderr will hang, e.g. CMake waits for the compilation commands:
https://gitlab.kitware.com/cmake/cmake/-/blob/0991023c30ed5b83bcb1446b5bcc9c1eae028835/Source/kwsys/ProcessUNIX.c#L1076

Fixes #47
real-or-random added a commit to real-or-random/secp256k1 that referenced this issue May 23, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
real-or-random added a commit to real-or-random/secp256k1 that referenced this issue Jun 1, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
hebasto pushed a commit to hebasto/secp256k1 that referenced this issue Jun 2, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
hebasto pushed a commit to hebasto/secp256k1 that referenced this issue Jun 2, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
hebasto pushed a commit to hebasto/secp256k1 that referenced this issue Jun 2, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
hebasto pushed a commit to hebasto/secp256k1 that referenced this issue Jun 3, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
dderjoel pushed a commit to dderjoel/secp256k1 that referenced this issue Jun 21, 2023
The underlying issue is now worked around in upstream, see
mstorsjo/msvc-wine#47 for details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants