Attempting to use chaos mode on Apple Silicon throws an assertion
Categories
(Core :: XPCOM, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox99 | --- | fixed |
People
(Reporter: mossop, Assigned: mossop)
Details
(Keywords: dogfood)
Attachments
(1 file)
Using a MBP with the M1 Max processor opt builds using chaos mode hang on startup. On debug builds we trigger an assertion in nsThread:
Assertion failure: false (thread_policy_set(mach_thread_self(), THREAD_AFFINITY_POLICY, &policy.affinity_tag, 1) == KERN_SUCCESS), at /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:263
#01: SetupCurrentThreadForChaosMode() (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x303de6)
#02: nsThread::InitCurrentThread() (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x304e68)
#03: nsThreadManager::Init() (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x30c37f)
#04: NS_InitXPCOM (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x353e00)
#05: ScopedXPCOMStartup::Initialize(bool) (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x602b65d)
#06: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6039503)
#07: XRE_main(int, char**, mozilla::BootstrapConfig const&) (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6039d65)
#08: main (/Users/dave/mozilla/build/trunk/obj-browser-dbg-artifact/dist/NightlyDebug.app/Contents/MacOS/firefox + 0x1138)
I guess thread_policy_set works differently on Apple Silicon but given the complete lack of documentation it is hard to tell.
This blocks doing test-verify runs locally.
|
Assignee | |
Comment 1•2 years ago
|
||
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #0)
I guess
thread_policy_setworks differently on Apple Silicon but given the complete lack of documentation it is hard to tell.
I had a quick look at their most recent kernel sources and it's probably not possible at the moment. The kernel honors thread affinity only if it knows that the processor it's running on has affinity sets, on ARM the number of sets is zero, so all functions manipulating thread affinity will fail. What's funny is that there seems to be an MSR on the M1 with bits that seem to be used to set affinities (see here) but it doesn't seem to be wired up to any code that's surfaced to userspace. I suspect this might be a deliberate choice: in testing it seems that the kernel's QoS is capable of pinning tasks to certain cores to save power and increase responsiveness so they probably don't want applications to mess with that.
Pushed by dtownsend@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/909cd61ae4c5 Setting a thread's affinity is not supported on ARM64 chipset on macOS. r=nika
|
||
Comment 4•2 years ago
|
||
| bugherder | ||
Description
•