http://bugs.winehq.org/show_bug.cgi?id=15462
Summary: Wine blocking on exit when stdout and stderr are piped Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: chris@neko.net.nz
Created an attachment (id=16357) --> (http://bugs.winehq.org/attachment.cgi?id=16357) Output of two simultaneous runs of described script
The issue occurs when concurrently running shell scripts which call Wine processes whose standard out and standard error are both piped to another program.
When two instances of a script such as the following are run concurrently, the first child wine processes started by each of then run together, but in one of the scripts that child doesn't fully exit until the _other_ script has completely run and exited. (The Wine process terminates, but the pipeline doesn't complete and so the script doesn't continue.)
A bash test-case to show this behaviour is as follows:
for iter in first second ; do echo "[$$] running $iter child wine" `date`; wine sleep-long.exe 2>&1 | tee /dev/null; done; echo "[$$] done " `date`
The problem doesn't occur if either the redirection or pipe is removed, if I run the scripts in separate Wine environments using $WINEPREFIX, or if I have another long-lived Wine process which stays running throughout the entire operation.
An example run with timing is attached.
The test Wine program used above, 'sleep-long', is the following tiny C program (tested with Microsoft cl and Cygwin GCC with mingw):
#include <stdio.h> #include <windows.h> int main(){ printf("Started fake compiler, sleeping 8000ms\n"); Sleep(8000); printf("Exiting fake compiler\n"); exit(0); }
I've been able to reproduce this problem on several systems and Wine versions (Debian Lenny with distro-packaged Wine 1.0.0-1, Debian Etch with Wine 1.0-rc1-1~bpo40+1 from Debian backports, Ubuntu Dapper with distro-packaged Wine 0.9.9-0ubuntu2) but not on one other (Debian Etch with distro-packaged Wine 0.9.25-2.1)
http://bugs.winehq.org/show_bug.cgi?id=15462
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=15462
--- Comment #1 from Austin English austinenglish@gmail.com 2009-03-30 13:29:01 --- Is this still an issue in current (1.1.18 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=15462
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #2 from Austin English austinenglish@gmail.com 2009-10-01 14:57:56 --- Is this still an issue in current (1.1.30 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=15462
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Abandoned? CC| |frederic.delanoy@gmail.com
--- Comment #3 from Frédéric Delanoy frederic.delanoy@gmail.com 2011-09-17 11:53:26 CDT --- Is this still an issue in current (1.3.28 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=15462
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |dank@kegel.com Ever Confirmed|0 |1
--- Comment #4 from Dan Kegel dank@kegel.com 2011-09-17 12:26:18 CDT --- Yes, this is still an issue. It's easy to reproduce. Just run his command in two windows at the same time.
http://bugs.winehq.org/show_bug.cgi?id=15462
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|Abandoned? |
http://bugs.winehq.org/show_bug.cgi?id=15462
--- Comment #5 from Dan Kegel dank@kegel.com 2013-03-28 18:02:16 CDT --- It still sounds interesting.
http://bugs.winehq.org/show_bug.cgi?id=15462
Andrey Turkin andrey.turkin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.turkin@gmail.com
--- Comment #6 from Andrey Turkin andrey.turkin@gmail.com 2013-05-21 02:29:00 CDT --- Here's that happens: 1) One wine process forks off wineserver which would leave stderr open in case it needs to dump some traces or error messages; this stderr handle (inherited from wine process) is connected to write side of a pipe which tee reads 2) wine process for another script instance uses this wineserver for its operation 3) wine process that initially started wineserver exits; wineserver still lingers for few more seconds; tee waits for all the writers to go away 4) second wine process in another script instance starts up, connects to the wineserver and runs to completion 5) wineserver waits for few seconds again, then exits 6) tee exits, second wine process is started (starting new wineserver)
Basically the question here is when wineserver should close its inherited stderr when implicitly started in background by wine (right away from the start, or when program that spawned wineserver exits, or when all non-system programs started by that original program exited, or never, or something else). Also there is an obvious workaround described by Chris - just start some wine application beforehand to make sure wineserver is there.
http://bugs.winehq.org/show_bug.cgi?id=15462
--- Comment #7 from Micha Nelissen micha@neli.hopto.org 2013-11-23 06:40:04 CST --- Created attachment 46618 --> http://bugs.winehq.org/attachment.cgi?id=46618 Patch that daemonizes wineserver, fixes issue
I have attached a patch that fixes the issue for me. I'm using wine to run the MSVC compiler.
The patch creates a daemon.err logfile in the wine server dir (/tmp/.wine-XXX/YYY/), where the output of wineserver.exe, services.exe, and all other background processes go.
I've removed the inheritance of stdin/stdout/stderr in server/process.c (that took some time to find!) because in windows, either you set bInheritHandles to true with CreateProcess and you inherit stdin etc too, or you set it false, and you get nothing. So this patch should also increase winapi compatibility.
http://bugs.winehq.org/show_bug.cgi?id=15462
Micha Nelissen micha@neli.hopto.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |micha@neli.hopto.org
http://bugs.winehq.org/show_bug.cgi?id=15462
--- Comment #8 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-11-23 10:10:24 CST --- (In reply to comment #7)
Created attachment 46618 [details] Patch that daemonizes wineserver, fixes issue
I have attached a patch that fixes the issue for me. I'm using wine to run the MSVC compiler.
The patch creates a daemon.err logfile in the wine server dir (/tmp/.wine-XXX/YYY/), where the output of wineserver.exe, services.exe, and all other background processes go.
I've removed the inheritance of stdin/stdout/stderr in server/process.c (that took some time to find!) because in windows, either you set bInheritHandles to true with CreateProcess and you inherit stdin etc too, or you set it false, and you get nothing. So this patch should also increase winapi compatibility.
You probably would want to send it to wine-patches, or wine-devel mailing list if you want some kind of review.
Patches are not picked up from bugzilla
http://bugs.winehq.org/show_bug.cgi?id=15462
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=15462
Detlef Riekenberg wine.dev@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev@web.de
https://bugs.winehq.org/show_bug.cgi?id=15462
Andrey andrey.gursky@e-mail.ua changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.gursky@e-mail.ua
https://bugs.winehq.org/show_bug.cgi?id=15462
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com Keywords| |patch