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(a)winehq.org Reporter: bernhardu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.