https://bugs.winehq.org/show_bug.cgi?id=44816
Bug ID: 44816 Summary: Cygwin/MSYS2 `script -e` exit status forwarding randomly returns zero for non zero child process Product: Wine Version: 3.4 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: focht@gmx.net Distribution: ---
Hello folks,
to track https://github.com/wine-staging/wine-staging/tree/master/patches/ntdll-Deall...
Mentioned here:
https://wine-staging.com/news/2015-08-23-release-1.7.50.html
--- quote --- Do not allow to deallocate thread stack for current thread (MSYS2, Wine Staging Bug #241) --- quote ---
After some archaeology I found the Cygwin mailing list discussion here:
https://cygwin.com/ml/cygwin/2015-09/msg00114.html
--- quote ---
Ah, ok. What OS does Wine emulate here? Have a look at https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/cygth...
The terminate_thread_frees_stack flag is set to false for XP/2003 and to true for any newer OS. I guess this is a double-free because Wine's TerminateThread already freed the stack and Cygwin got the info it's supposedly running under XP/2003, so it tries to workaround the fact that TerminateThread on these systems didn't free the stack by themselves.
Wine emulates Windows XP here, I double checked Wine source code and I can confirm Wine doesn't free the stack: NtTerminateThread() -> abort_thread() -> terminate_thread() https://github.com/wine-compholio/wine-patched/blob/8b3a785e97a7e28ff58731b5...
Cygwin reports wincap as wincap_xpsp2 which is also correct here.
we need to know what address ret=61005767 is refering to. addr2line would help.
As you point out, ret=61005767 is the call to VirtualFree() inside cygthread::terminate_thread () https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/cygth...
After combine the information we have so far, I think the problem is clear now. It's not Cygwin's fault, it's Wine's fault. Wine's WaitForSingleObject() needs to wait long enough after the TerminateThread() call, so the target thread has enough time to finish the system cleanup and return correct exit_code before Cygwin call VirtualFree to free the stack. But in our current implementation Wine's WaitForSingleObject returns too early, it shouldn't return before the system thread cleanup done, as a result there is a race here. We are thinking of a solution in Wine. Thanks again for the great help! --- quote ---
$ wine --version wine-3.4
Regards
https://bugs.winehq.org/show_bug.cgi?id=44816
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://cygwin.com/install. | |html Status|NEW |STAGED Keywords| |download, patch, source Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/ntdll-Dealloc_Th | |read_Stack
https://bugs.winehq.org/show_bug.cgi?id=44816
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=44816
Andrey andrey.gursky@e-mail.ua changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.gursky@e-mail.ua
https://bugs.winehq.org/show_bug.cgi?id=44816
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- I'm guessing the double-free results from the kernel freeing the thread's stack once it's terminated (I'm not sure, and it's hard to be sure just from skimming the kernel code, but it seems like the only sane thing to do?) since we certainly don't free it ourselves.
https://bugs.winehq.org/show_bug.cgi?id=44816
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- (In reply to Zebediah Figura from comment #1)
I'm guessing the double-free results from the kernel freeing the thread's stack once it's terminated (I'm not sure, and it's hard to be sure just from skimming the kernel code, but it seems like the only sane thing to do?) since we certainly don't free it ourselves.
Actually, on further testing, it seems the kernel doesn't free anything. So what gives? How could there possibly be a double free here?
https://bugs.winehq.org/show_bug.cgi?id=44816
Joel Holdsworth joel@airwebreathe.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joel@airwebreathe.org.uk
https://bugs.winehq.org/show_bug.cgi?id=44816
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- This patch got removed from the wine-staging patch set here:
https://gitlab.winehq.org/wine/wine-staging/-/commit/e3cca687befffb4baee144d...
On top of current wine git plus a few patches needed for msys2 installation, I tried to reproduce this issue with a current 64-bit msys2 and the latest available 32-bit cygwin installation, but following command returned always the same expected value to me.
while true; do script -e -q -c 'bash.exe -c "exit 123"' -a tmp.txt; echo $? $(date); done
As staging patch got removed and the issue seems no longer visible, should this bug be closed?
https://bugs.winehq.org/show_bug.cgi?id=44816
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |25b093f3845a0ae1b2e2fe1c070 | |1e98064f8e8d6 Status|STAGED |RESOLVED Resolution|--- |FIXED
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- (In reply to Bernhard Übelacker from comment #3)
This patch got removed from the wine-staging patch set here:
https://gitlab.winehq.org/wine/wine-staging/-/commit/ e3cca687befffb4baee144dcd55f01a3204176eb
On top of current wine git plus a few patches needed for msys2 installation, I tried to reproduce this issue with a current 64-bit msys2 and the latest available 32-bit cygwin installation, but following command returned always the same expected value to me.
while true; do script -e -q -c 'bash.exe -c "exit 123"' -a tmp.txt; echo $? $(date); done
As staging patch got removed and the issue seems no longer visible, should this bug be closed?
I think it's fair to assume so, yes. Should be fixed by https://source.winehq.org/git/wine.git/commitdiff/25b093f3845a0ae1b2e2fe1c0701e98064f8e8d6 or the i386 version.
https://bugs.winehq.org/show_bug.cgi?id=44816
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.14.