http://bugs.winehq.org/show_bug.cgi?id=33654
Bug #: 33654 Summary: MSYS bash.exe redirection fails for ctest.exe (one of the CMake executables). Regression of recent wine-git from 1.5.25 Product: Wine Version: 1.5.31 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs@winehq.org ReportedBy: irwin@beluga.phys.uvic.ca Classification: Unclassified
Created attachment 44546 --> http://bugs.winehq.org/attachment.cgi?id=44546 Source code for "DoNotInheritStdPipes" redirection test
Under MSYS bash.exe, redirection of the ctest.exe command produces an empty file for wine-1.5.31 but not for wine-1.5.19 (very heavily tested for my build needs) or wine-1.5.25 (lightly tested for this specific problem). For example, in 1.5.31, but not 1.5.25 (or 1.5.19),
ctest.exe --version
gives the correct result ("ctest version 2.8.10.2") to the console created by wineconsole, but
ctest.exe --version > ctest_version.out
produces an empty file.
"git bisect" shows the first wine commit to cause the problem was the first one after 1.5.25 (f565e4a3157d38b50a25fc3b90014474b59fceba, msvcrt: Don't duplicate standard handles during initialization.) Subsequently there was a style change (8e5bebe26253f2725141a35f23b6f2e10fc7694d, msvcrt: Rename msvcrt_alloc_fd_from to msvcrt_set_fd.) to the affected file, dlls/msvcrt/file.c. Both these commits were by Piotr Caban piotr@codeweavers.com. If I revert 8e5bebe26253f2725141a35f23b6f2e10fc7694d and f565e4a3157d38b50a25fc3b90014474b59fceba for wine-1.5.31 (note the reversed patches apply cleanly), this fixes the issue.
To save wine developers having to dig around in the ctest code source from CMake to figure out what Windows calls are being used to trigger this wine regression, I attach standalone code for a simple test case which follows what is done in ctest to handle stdout. When this code is compiled with MinGW it demonstrates the same redirection issue you get with ctest. The only difference from a standard C++ "Hello World" programme in this test code is the call to DoNotInheritStdPipes which I just copied from the ctest source code. I don't understand DoNotInheritStdPipes, but one of the commit messages associated with it when it was implemented in 2007 by the CMake developers had the title "BUG: fix problem with stdout and stderr not showing up in ms dos shells". Anyhow, since 2007 DoNotInheritStdPipes has apparently been used for executing ctest.exe on Microsoft Windows with no redirection issues on that platform and that implies commit f565e4... causes a run-time difference between the Wine and Microsoft versions of Windows. But I have no access to Microsoft Windows myself so that implication should be confirmed by compiling the attached source code on Microsoft Windows and showing that redirection works fine with it under MSYS bash.exe for that platform but not for wine-1.5.31 unless the two above patches (one just a style one) are reverted.
http://bugs.winehq.org/show_bug.cgi?id=33654
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com Regression SHA1| |f565e4a3157d38b50a25fc3b900 | |14474b59fceba
http://bugs.winehq.org/show_bug.cgi?id=33654
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #44546|0 |1 is obsolete| |
--- Comment #1 from Piotr Caban piotr.caban@gmail.com 2013-05-25 05:13:52 CDT --- Created attachment 44548 --> http://bugs.winehq.org/attachment.cgi?id=44548 DuplicateHandle test
There seems to be some kind of optimization in native implementation of DuplicateHandle function. In some cases when DUPLICATE_CLOSE_SOURCE flag is used output and input handles are identical. Thanks to it a handle stored inside msvcrt remains valid on windows. DuplicateHandle behavior is identical on all testbot machines.
Output of attached program, Win7: in = 0000000B 1: in = 0000000B, out = 00000007, (in==out) = 0 in = 000000C4 1: in = 000000C4, out = 000000C4, (in==out) = 1 in = 000000C4 1: in = 000000C4, out = 000000C4, (in==out) = 1
Wine: in = 0000001B 1: in = 0000001B, out = 00000027, (in==out) = 0 in = 00000018 1: in = 00000018, out = 00000028, (in==out) = 0 in = 00000018 1: in = 00000018, out = 00000028, (in==out) = 0
http://bugs.winehq.org/show_bug.cgi?id=33654
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msvcrt |ntdll
http://bugs.winehq.org/show_bug.cgi?id=33654
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=33654
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|MSYS bash.exe redirection |MSYS bash.exe redirection |fails for ctest.exe (one of |fails for ctest.exe (one of |the CMake executables). |the CMake executables) |Regression of recent | |wine-git from 1.5.25 |
http://bugs.winehq.org/show_bug.cgi?id=33654
--- Comment #2 from Piotr Caban piotr.caban@gmail.com 2013-06-05 16:23:53 CDT --- It's probably fixed. Please retest.
http://bugs.winehq.org/show_bug.cgi?id=33654
--- Comment #3 from Alan W. Irwin irwin@beluga.phys.uvic.ca 2013-06-06 01:01:55 CDT --- ctest --version > whatever now generates a correct non-empty "whatever" file, and my MinGW/MSYS-based automated build script for what are now 5 separate software projects finishes without errors. These good results were achieved for wine-git from today (wine-1.5.31-204-g1319515) and also for wine-1.5.31 with two regression-fix patches applied (598ff4dd5a44e1632e9eb2bf6d59a2a363afe854 which is Piotr's fix for bug 33715 and 76bfbf43e99d102a2ae701b5e1a9cc9682f2494a which is Piotr's fix for the current bug). I therefore suggest you change the status of the current bug to resolved fixed.
Thanks, Piotr, for dealing with both these regressions, and because of your efforts I am pretty sure wine-1.5.32 will be just as good as wine-1.5.19 from my "build software projects" needs. The caveat, of course, is my automated build script currently only builds a subset of the software projects that I built successfully for wine-1.5.19 by hand, but I am actively working on increasing the scope of that script to more software projects so the prospects are good that wine-1.5.32 will be tested as a MinGW/MSYS build platform by me as extensively as I tested wine-1.5.19.
http://bugs.winehq.org/show_bug.cgi?id=33654
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |76bfbf43e99d102a2ae701b5e1a | |9cc9682f2494a Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #4 from Piotr Caban piotr.caban@gmail.com 2013-06-06 04:06:02 CDT --- Marking as fixed.
http://bugs.winehq.org/show_bug.cgi?id=33654
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2013-06-07 15:01:56 CDT --- Closing bugs fixed in 1.6-rc1.