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.

Sign up for GitHub

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

Jump to bottom

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

Merged
merged 2 commits into from
Nov 13, 2024
Merged

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

merged 2 commits into from
Nov 13, 2024

Commits on Nov 12, 2024

  1. Cygwin: find_fast_cwd: don't run assembler checking code on ARM64 

    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]>
    @github-cygwin @jeremyd2019
    github-cygwin authored and jeremyd2019 committed Nov 12, 2024
    Configuration menu
    Copy the full SHA
    28136da View commit details
    Browse the repository at this point in the history

  2. cygthread: suspend thread before terminating. 

    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
    jeremyd2019 committed Nov 12, 2024
    Configuration menu
    Copy the full SHA
    cbdbe8c View commit details
    Browse the repository at this point in the history