[macOS 11] Running asm.js code on profiler.firefox.com crashes the tab on Big Sur
Categories
(Core :: JavaScript: WebAssembly, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | --- | verified |
People
(Reporter: csasca, Assigned: dbezhetskov)
References
(Regression)
Details
(Keywords: regression)
Affected versions
- Firefox 81.0a1
Affected platforms
- macOS 11 (public beta 1)
Steps to reproduce
- Launch Firefox
- Start capturing a profile with gecko profiler
- On the profile page, click on Publish
Expected result
- The profile is published
Actual result
- The tab will crash
Regression range
- This is not a regression, as it's only affecting macOS 11
Additional notes
- The issue can be seen in the following attachment
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Do you see the crash n about:crashes ? Could you please share the link to that crash information? Thanks !
I think this happens when symbolicating, maybe something changed in the object format? (Related to the new architecture maybe?)
Comment 2•4 years ago
|
||
If the crash happens during publishing, it's a JS engine bug. There's a piece of asm.js code running in a worker on profiler.firefox.com when a profile is published, to gzip-compress the data.
(In reply to Catalin Sasca, QA [:csasca] from comment #0)
Regression range
- This is not a regression, as it's only affecting macOS 11
It could still be a regression. And according to bug 1657892 comment 2, there is no crash on Firefox Beta. Could you please find a regression range?
Comment 3•4 years ago
|
||
I am seeing a similar crash on macOS 10.15 in a local Firefox build. It's possible that this is not a macOS 11 issue after all.
Process 36366 stopped
* thread #34, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
frame #0: 0x0000000104efde17 XUL`MachExceptionHandlerThread() [inlined] HandleTrap(context=<unavailable>, isUnalignedSignal=false, assertCx=0x0000000000000000) at WasmSignalHandlers.cpp:712:55 [opt]
709 // though, the containing JSContext is the same.
710
711 auto* frame = reinterpret_cast<Frame*>(ContextToFP(context));
-> 712 Instance* instance = GetNearestEffectiveTls(frame)->instance;
713 MOZ_RELEASE_ASSERT(&instance->code() == &segment.code() ||
714 trap == Trap::IndirectCallBadSig);
715
Target 0: (plugin-container) stopped.
(lldb) bt
* thread #34, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
* frame #0: 0x0000000104efde17 XUL`MachExceptionHandlerThread() [inlined] HandleTrap(context=<unavailable>, isUnalignedSignal=false, assertCx=0x0000000000000000) at WasmSignalHandlers.cpp:712:55 [opt]
frame #1: 0x0000000104efdd45 XUL`MachExceptionHandlerThread() at WasmSignalHandlers.cpp:844 [opt]
frame #2: 0x0000000104efdce0 XUL`MachExceptionHandlerThread() at WasmSignalHandlers.cpp:896 [opt]
frame #3: 0x00000001048ea950 XUL`js::detail::ThreadTrampoline<void (&)()>::Start(void*) [inlined] void js::detail::ThreadTrampoline<void (&)()>::callMain<>(this=0x000000014a3d4f40) at Thread.h:217:5 [opt]
frame #4: 0x00000001048ea93a XUL`js::detail::ThreadTrampoline<void (&)()>::Start(aPack=0x000000014a3d4f40) at Thread.h:206 [opt]
frame #5: 0x00007fff71252109 libsystem_pthread.dylib`_pthread_start + 148
frame #6: 0x00007fff7124db8b libsystem_pthread.dylib`thread_start + 15
Comment 4•4 years ago
|
||
This is probably a regression from bug 1639153, which has already been backed out, so this should be fixed.
Updated•4 years ago
|
Reporter | ||
Comment 5•4 years ago
|
||
Yep, this tab crash is no longer happening on 81.0a1 (2020-08-09). It is safe to close this issue.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
I can confirm this issue is fixed, I verified using Firefox 81.0b8 on macOS 11.0.
Description
•