https://bugs.winehq.org/show_bug.cgi?id=55138
Bug ID: 55138 Summary: msys2: bash.exe is not able to fork/start another process. Product: Wine Version: 8.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: bernhardu@mailbox.org Distribution: ---
Created attachment 74697 --> https://bugs.winehq.org/attachment.cgi?id=74697 allocation stacks in parent and child bash.exe
This is a followup to bug 47808. If I understand it right, bug 47808 was primarily about native libraries getting called at a win32 stack which was not yet committed. Those native libraries then jumped over the guard page, therefore the stack got not grown, instead a crash reported. This aspect was fixed by using the syscall interface and therefore bug 47808 was closed.
But there is another issue that causes a msys2-forked process crashing, because after the stack was grown it still misses the PAGE_READWRITE flags.
For this Zeb Figura included in the first attachement to bug 47808 "always expand the stack if within the stack reserve" a line adding the flags "VPROT_COMMITTED | VPROT_READ | VPROT_WRITE" to the page that gets the VPROT_GUARD removed in grow_thread_stack.
This modification still enables a forked process to run.
The issue can be reproduced with an unmodified wine by just - running msys2 bash.exe interactively - then trying to start e.g. notepad from it.
Attached file shows the stack when the stack gets allocated - in a working msys2-parent process and - in a failing msys2-forked child process.
Therefore it looks like the forked stack get really setup differently, but it is still not clear if or when this memory gets the READ/WRITE added in native windows.