Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backport arm64 fixes for msys2-3_3_6-release #235

Merged
merged 2 commits into from
Nov 13, 2024

Conversation

jeremyd2019
Copy link
Member

@jeremyd2019 jeremyd2019 commented Nov 13, 2024

Since I already did this for testing on Windows 10 ARM64, I thought I'd open a PR for these too. This is effectively #233 and #234

github-cygwin and others added 2 commits November 12, 2024 14:28
https://cygwin.com/pipermail/cygwin/2024-February/255397.html
reports a crash on ARM64 probably related to checking x86_64
code on the x86_64 emulator on AArch64.

At least for testing, pull the code checking the host HW
up to be called before trying to evaluate assembler code.

Signed-off-by: Corinna Vinschen <[email protected]>
This addresses an extremely difficult to debug deadlock when running
under emulation on ARM64.

A relatively easy way to trigger this bug is to call `fork()`, then within the
child process immediately call another `fork()` and then `exit()` the
intermediate process.

It would seem that there is a "code emulation" lock on the wait thread at
this stage, and if the thread is terminated too early, that lock still exists
albeit without a thread, and nothing moves forward.

It seems that a `SuspendThread()` combined with a `GetThreadContext()`
(to force the thread to _actually_ be suspended, for more details see
https://devblogs.microsoft.com/oldnewthing/20150205-00/?p=44743)
makes sure the thread is "booted" from emulation before it is suspended.

Hopefully this means it won't be holding any locks or otherwise leave
emulation in a bad state when the thread is terminated.

Also, attempt to use `CancelSynchonousIo()` (as seen in `flock.cc`) to avoid
the need for `TerminateThread()` altogether.  This doesn't always work,
however, so was not a complete fix for the deadlock issue.

Addresses: https://cygwin.com/pipermail/cygwin-developers/2024-May/012694.html
Signed-off-by: Jeremy Drake <[email protected]>
@jeremyd2019
Copy link
Member Author

I don't use msys2-runtime-3.4, and don't see any use case for it on arm64, so I haven't tried to backport anything to it.

@lazka lazka merged commit 32c179d into msys2:msys2-3_3_6-release Nov 13, 2024
1 check passed
@jeremyd2019 jeremyd2019 deleted the msys2-3_3_6-test-arm64 branch November 13, 2024 19:19
lazka added a commit to lazka/MSYS2-packages that referenced this pull request Nov 13, 2024
@lazka
Copy link
Member

lazka commented Nov 13, 2024

-> msys2/MSYS2-packages#5006

lazka added a commit to msys2/MSYS2-packages that referenced this pull request Nov 13, 2024
@dscho
Copy link
Collaborator

dscho commented Nov 14, 2024

Does this also need #236?

@jeremyd2019
Copy link
Member Author

yes. I was waiting for confirmation that it fixed the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants