Repository navigation
Fix suspend of CLR initialization thread when started from dispatch queue on apple - #135276
Merged
Merged
Conversation
…patch queue on apple Suspending for GC requires first sending a signal to a thread (so that we can check the thread context and determine what action needs to be taken for suspending this thread at a GC safe location). On apple platforms, threads dispatched via `dispatch_async` have this signal masked (`INJECT_ACTIVATION_SIGNAL`). When a foreign thread is attached to the runtime, it goes through `AllocatePalThread` path, which already does the necessary unmasking of the signal. When CoreCLR was started from a thread dispatched via `dispatch_async`, which is the case in the mobile tests runner, we weren't unmasking the signal for this initial thread. This resulted in a thread potentially never stopping from GC and the app hanging. macios never initializes CoreCLR from such a worker thread, so this fix is targeted only to our testing. Reenable test
Contributor
|
Tagging subscribers to this area: @agocke |
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
BrzVlad
commented
Oct 6, 2026
This was referenced Oct 6, 2026
Open
janvorli
reviewed
Oct 13, 2026
janvorli
reviewed
Oct 13, 2026
janvorli
approved these changes
Oct 14, 2026
jkotas
approved these changes
Oct 15, 2026
This was referenced Oct 15, 2026
Closed
Member
Author
|
/ba-g failures unrelated |
XLord-Heliukum
added a commit
to Open-code-Studio/CodeNet
that referenced
this pull request
Oct 17, 2026
现象:macOS 27 上 CodeNet 运行时在 GC 标记阶段 SIGSEGV/SIGBUS, 栈为 mark_object_simple1 <- mark_object_simple <- GcStackCrawlCallBack <- EnumerateLiveSlots <- Promote <- gc_heap::mark_phase, 且把栈上的 ASCII 数据当成对象指针解引用。WKS 与 SVR 都能复现。 根因:GC 要挂起线程得先给线程发注入激活信号(INJECT_ACTIVATION_SIGNAL)。 由 launchd / libdispatch 起出来的线程进入进程时该信号是屏蔽的, GC 于是永远等不到线程停到 safepoint,继续扫描一个还在跑的栈, 把任意栈内容当成对象引用 —— 这就是 mark 阶段的崩溃。 上游同类问题的修法见 dotnet/runtime#135276(BrzVlad): 把 PAL 内部的 UnmaskActivationSignal 导出成 PAL_UnmaskActivationSignal, 并在 CLR 侧线程挂接时调用。本仓库按同样思路移植, 区别是挂在 SetThread 的通用挂接路径上(而不是只处理初始线程), 因为这里的成灾面是所有继承了启动者信号掩码的线程。 改动: - pal.h 导出 PAL_UnmaskActivationSignal - signal.cpp 增加 extern "C" 导出包装(CodeNet 强制 HAVE_MACH_EXCEPTIONS=0, 该文件信号路径必被编译) - threads.cpp 的 SetThread 在 InitRuntimeThreadLocals 之后解除屏蔽 附带:SDK 组装脚本关掉 SDK CLI 自身的并发 GC(治标,压住构建期的偶发崩溃), 产物校验从「与骨架原件哈希不同」改成「与运行时源文件哈希一致」, 并新增 scripts/codenet-sdk/verify-stability.sh 做本机回归。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Suspending for GC requires first sending a signal to a thread (so that we can check the thread context and determine what action needs to be taken for suspending this thread at a GC safe location). On apple platforms, threads dispatched via
dispatch_asynchave this signal masked (INJECT_ACTIVATION_SIGNAL). When a foreign thread is attached to the runtime, it goes throughAllocatePalThreadpath, which already does the necessary unmasking of the signal. When CoreCLR was started from a thread dispatched viadispatch_async, which is the case in the mobile tests runner, we weren't unmasking the signal for this initial thread. This resulted in a thread potentially never stopping from GC and the app hanging.macios never initializes CoreCLR from such a worker thread, so this fix is targeted only to our testing.
Fixes #134770