http://bugs.winehq.org/show_bug.cgi?id=16957
Summary: CreateProcess handles are inherited even when bInheritHandles=FALSE Product: Wine Version: 1.1.2 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: kernel32 AssignedTo: wine-bugs@winehq.org ReportedBy: ben@salilab.org
Created an attachment (id=18729) --> (http://bugs.winehq.org/attachment.cgi?id=18729) test.c
The attached file uses CreateProcess to create a subprocess (gzip in this case) with redirected standard output. In order for this to work properly, the output handle created in this code must be inherited by the subprocess - thus the bInheritHandles argument to CreateProcess must be TRUE. And indeed if this program is compiled to test-true.exe, a simple text file 'test.in' and the gzip binary are placed in the same directory, and then test-true.exe is run, it successfully produces the output test.gz.
If the TRUE argument is switched to FALSE and the file is compiled again to test-false.exe, when the program is run in the same way on a 'real' Windows sytem (32 bit Vista Business in this case) the following is output:
gzip: stdout: Bad file descriptor
This is also fine and expected, since the output file handle was not passed to gzip. *However* if the same test-false.exe program is run with Wine (the Fedora 10 wine-core-1.1.12-1.fc10.i386 package in this case) it runs in just the same way as test-true.exe, generating the test.gz output.
This suggests to me that the bInheritHandles argument is ignored by Wine. As stated, this is a minor bug but it would be nice if Wine behaved the same way as Windows here. (In our case we discovered this problem after we tested our program successfully under Wine, but then had it fail on a real Windows system.) I am not familiar with the code, but hopefully it should be straightforward enough to provide the subprocess with invalid handles if bInheritHandles=FALSE?
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2009-01-16 09:33:59 --- No, bInheritHandles is implemented properly, but there is special magic for stdio handles. Some more test cases would be needed to figure out the exact cause of the different behavior.
http://bugs.winehq.org/show_bug.cgi?id=16957
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #2 from Austin English austinenglish@gmail.com 2009-07-21 14:07:36 --- Is this still an issue in current (1.1.26 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #3 from Ben Webb ben@salilab.org 2009-07-21 19:14:16 --- (In reply to comment #2)
Is this still an issue in current (1.1.26 or newer) wine?
I just tried the testcase on my Fedora 11 box, which runs wine 1.1.23, and it still fails in the same fashion. I don't have an installation of wine 1.1.26 to test this on though.
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #4 from Austin English austinenglish@gmail.com 2010-07-23 15:33:11 --- On wine/windows, both with TRUE and FALSE, I get
System command failed with code 2: gzip -c test.in
though wine adds in wine: cannot find L"C:\windows\system32\gzip.exe"
did you install a native gzip? Or were you using the systems?
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #5 from Ben Webb ben@salilab.org 2010-07-23 16:13:40 --- (In reply to comment #4)
On wine/windows, both with TRUE and FALSE, I get
System command failed with code 2: gzip -c test.in
though wine adds in wine: cannot find L"C:\windows\system32\gzip.exe"
Right, because in both cases it can't find the gzip binary. You need to put a gzip binary in the same directory as the test file, as I explained in my original report. I got mine from http://gnuwin32.sourceforge.net/packages/gzip.htm but I can attach gzip.exe itself to this bug report if you don't mind running untrusted binaries on your system.
did you install a native gzip? Or were you using the systems?
It's a native Win32 binary, not the Linux gzip.
BTW, I just tested this again on my Fedora 13 box (running wine 1.2.0). Still fails[*] as originally reported.
[*] By "fails" I mean it doesn't report an error when it should, in the second case (with the FALSE argument).
http://bugs.winehq.org/show_bug.cgi?id=16957
xlq jp.sittingduck+winehq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jp.sittingduck+winehq@gmail | |.com
--- Comment #6 from xlq jp.sittingduck+winehq@gmail.com 2010-08-01 10:07:07 --- I can confirm this bug in wine-1.2. I just hit it while developing Windows code with Wine, and then moving it to Windows. The attached test.c uses a regular file but I used a pipe and got exactly the same behaviour in both Windows and Wine.
To be fair the Windows documentation is quite ambiguous on the matter. Empirically, Windows certainly doesn't do anything special with the stdio handles in STARTUPINFO.
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #7 from butraxz@gmail.com 2013-03-04 14:49:47 CST --- This has not been updated for two years. Is this an issue in 1.5.25 or should this be closed as abandoned ?
http://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #8 from Ben Webb ben@salilab.org 2013-03-04 15:42:07 CST --- I certainly haven't abandoned it - I provided a test case to demonstrate the problem, and checked it again when asked on a newer version of Wine. Do you want me to check again with latest Wine? I am happy to do that if it's likely to result in the bug being fixed.
https://bugs.winehq.org/show_bug.cgi?id=16957
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=16957
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #9 from Gijs Vermeulen gijsvrm@gmail.com --- The TRUE and FALSE results are still the same with wine-5.17.
https://bugs.winehq.org/show_bug.cgi?id=16957
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com Keywords| |source
https://bugs.winehq.org/show_bug.cgi?id=16957
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=16957
huangqinjin huangqinjin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |huangqinjin@gmail.com
--- Comment #10 from huangqinjin huangqinjin@gmail.com --- Created attachment 74440 --> https://bugs.winehq.org/attachment.cgi?id=74440 std handles are inherited even when bInheritHandles=FALSE
The issue still exists in wine-8.6. I attached a simple repro. On Windows, the output is 0, means that subprocess cannot access the handle created by parent. On wine, the output is 4, means that even bInheritHandles=FALSE, subprocess can still access the file through stdout and stderr, but it cannot access through the inherited handle value.
https://bugs.winehq.org/show_bug.cgi?id=16957
--- Comment #11 from Eric Pouech eric.pouech@gmail.com --- this should be fixed in wine 9.0-rc1 running locally gives:
[bz16957]$ WINEDEBUG=fixme-all ../../wine64/wine test.exe 0
-
wine-bugs＠winehq.org -
WineHQ Bugzilla