Closed Bug 1657917 Opened 2 years ago Closed 2 years ago

[macOS 11] Running asm.js code on profiler.firefox.com crashes the tab on Big Sur

Categories

(Core :: JavaScript: WebAssembly, defect)

Desktop
macOS
defect

Tracking

()

RESOLVED FIXED
81 Branch
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

  1. Launch Firefox
  2. Start capturing a profile with gecko profiler
  3. 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
Has Regression Range: --- → no
Has STR: --- → yes
Blocks: 1648487

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?)

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?

Component: Gecko Profiler → Javascript: WebAssembly
Flags: needinfo?(catalin.sasca)
Summary: [macOS 11] Gecko profiler gets a tab crash when trying to publish a profile → [macOS 11] Running asm.js code on profiler.firefox.com crashes the tab on Big Sur

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

This is probably a regression from bug 1639153, which has already been backed out, so this should be fixed.

No longer blocks: 1648487
Regressed by: 1639153

Yep, this tab crash is no longer happening on 81.0a1 (2020-08-09). It is safe to close this issue.

Flags: needinfo?(catalin.sasca)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Severity: normal → --
Flags: qe-verify+

I can confirm this issue is fixed, I verified using Firefox 81.0b8 on macOS 11.0.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.