Closed Bug 1782160 Opened 2 years ago Closed 2 years ago

Local Nightly builds crash in libunwind.dylib when displaying system print dialog on Apple Silicon

Categories

(Core :: Widget: Cocoa, defect, P2)

Product:
Core
Component:
Widget: Cocoa
Platform:
Desktop
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
108 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox107 --- unaffected
firefox108 --- fixed

People

(Reporter: haik, Assigned: glandium)

References

(Regression)

Details

(Keywords: regression)

Crash Data

On macOS 13 Beta 4 22A5311f, the cause of bug 1778602 has been fixed, but now when opening the system print dialog on a local Nightly build, the browser crashes. Official channel builds don't encounter the crash. ASAN build console output below (the crash happens on regular debug/non-debug builds too.)

On bug 1778602 comment 11, :smichaud pointed out this problem is not reproducible on Intel and this might be related to symbol generation on Apple Silicon. More debugging needed.

AddressSanitizer:DEADLYSIGNAL
=================================================================
==31763==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0001a8ae3440 bp 0x32090001a8ae54fc sp 0x00016bd20930 T0)
==31763==The signal is caused by a UNKNOWN memory access.
==31763==Hint: address points to the zero page.
    #0 0x1a8ae3440 in libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE(libunwind::LocalAddressSpace&, unsigned long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::FDE_Info*, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*)+0x30 (libunwind.dylib:arm64+0x5440) (BuildId: 9384ce37a21e34e983389d6ce4da66f532000000200000000100000000000d00)

==31763==Register values:
 x[0] = 0x0000000000000000   x[1] = 0x000000016bd21e28   x[2] = 0x000000016bd21df0   x[3] = 0x0000000000000000  
 x[4] = 0x000000016bd20880   x[5] = 0x000000016bd20848   x[6] = 0x0000010100000180   x[7] = 0xffffffff00000000  
 x[8] = 0x000000016bd22080   x[9] = 0x000000016bd22fe0  x[10] = 0x0000000003000000  x[11] = 0xffffffffffffffff  
x[12] = 0x00000001381a5dea  x[13] = 0x0000000000000007  x[14] = 0x0000000000000007  x[15] = 0x0000000003000000  
x[16] = 0x496e800126800cfc  x[17] = 0x0000000126800cfc  x[18] = 0x0000000000000000  x[19] = 0x000000016bd21e28  
x[20] = 0x0000000000000000  x[21] = 0x000000016bd21df0  x[22] = 0x0000000000000be0  x[23] = 0x0000000000000000  
x[24] = 0x0000000000000001  x[25] = 0x00000001380dbbad  x[26] = 0x000000012edd6258  x[27] = 0x000000012edd62e8  
x[28] = 0x00000001380dbc1e     fp = 0x000000016bd20990     lr = 0x32090001a8ae54fc     sp = 0x000000016bd20930  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (libunwind.dylib:arm64+0x5440) (BuildId: 9384ce37a21e34e983389d6ce4da66f532000000200000000100000000000d00) in libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE(libunwind::LocalAddressSpace&, unsigned long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::FDE_Info*, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*)+0x30
==31763==ABORTING
Blocks: 1773708
See Also: → 1778602

Stack trace from a debug build.

(lldb) bt
* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001a8ae3440 libunwind.dylib`libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE(libunwind::LocalAddressSpace&, unsigned long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::FDE_Info*, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 48
    frame #1: 0x00000001a8ae54fc libunwind.dylib`libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::step() + 204
    frame #2: 0x000000019d244eb0 libobjc.A.dylib`objc_addExceptionHandler + 68
    frame #3: 0x00000001a0a4b190 AppKit`-[NSApplication _commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:] + 736
    frame #4: 0x00000001a0a4ae28 AppKit`__35-[NSApplication runModalForWindow:]_block_invoke_2 + 36
    frame #5: 0x00000001a0a4ade8 AppKit`__35-[NSApplication runModalForWindow:]_block_invoke + 108
    frame #6: 0x00000001a0a4a6cc AppKit`_NSTryRunModal + 100
    frame #7: 0x00000001a0a4a58c AppKit`-[NSApplication runModalForWindow:] + 292
    frame #8: 0x00000001a0e167f0 AppKit`-[NSPrintPanel runModalWithPrintInfo:] + 408
    frame #9: 0x0000000288ae92d4 XUL`nsPrintDialogServiceX::ShowPrintDialog(this=0x00000001228fa140, aParent=0x0000000123cec7f0, aHaveSelection=false, aSettings=0x0000000123d97400) at nsPrintDialogX.mm:97:16
    frame #10: 0x00000002813f0304 XUL`_NS_InvokeByIndex at xptcinvoke_asm_aarch64.S:74
    frame #11: 0x00000002813f10d0 XUL`::NS_InvokeByIndex(that=0x00000001228fa140, methodIndex=4, paramCount=3, params=0x000000016fdf03d0) at xptcinvoke_aarch64.cpp:167:12
    frame #12: 0x0000000282adcad4 XUL`CallMethodHelper::Invoke(this=0x000000016fdf0388) at XPCWrappedNative.cpp:1626:10
    frame #13: 0x0000000282abd344 XUL`CallMethodHelper::Call(this=0x000000016fdf0388) at XPCWrappedNative.cpp:1179:19
    frame #14: 0x0000000282abcff0 XUL`XPCWrappedNative::CallMethod(ccx=0x000000016fdf0620, mode=CALL_METHOD) at XPCWrappedNative.cpp:1125:23
    frame #15: 0x0000000282abf3f4 XUL`XPC_WN_CallMethod(cx=0x000000010eb50c00, argc=3, vp=0x0000000113e13228) at XPCWrappedNativeJSOps.cpp:965:10
    frame #16: 0x000000028ca4fee0 XUL`CallJSNative(cx=0x000000010eb50c00, native=(XUL`XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) at XPCWrappedNativeJSOps.cpp:941), reason=Call, args=0x000000016fdf3cf0)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) at Interpreter.cpp:417:13
    frame #17: 0x000000028ca4fa00 XUL`js::InternalCallOrConstruct(cx=0x000000010eb50c00, args=0x000000016fdf3cf0, construct=NO_CONSTRUCT, reason=Call) at Interpreter.cpp:505:12
    frame #18: 0x000000028ca50650 XUL`InternalCall(cx=0x000000010eb50c00, args=0x000000016fdf3cf0, reason=Call) at Interpreter.cpp:572:10
    frame #19: 0x000000028ca504a8 XUL`js::CallFromStack(cx=0x000000010eb50c00, args=0x000000016fdf3cf0, reason=Call) at Interpreter.cpp:577:10
    frame #20: 0x000000028ca44e34 XUL`Interpret(cx=0x000000010eb50c00, state=0x000000016fdf4a98) at Interpreter.cpp:3325:16
    frame #21: 0x000000028ca39c5c XUL`js::RunScript(cx=0x000000010eb50c00, state=0x000000016fdf4a98) at Interpreter.cpp:389:13
    frame #22: 0x000000028ca4fbf8 XUL`js::InternalCallOrConstruct(cx=0x000000010eb50c00, args=0x000000016fdf4c50, construct=NO_CONSTRUCT, reason=Call) at Interpreter.cpp:537:13
    frame #23: 0x000000028ca50650 XUL`InternalCall(cx=0x000000010eb50c00, args=0x000000016fdf4c50, reason=Call) at Interpreter.cpp:572:10
    frame #24: 0x000000028ca507f0 XUL`js::Call(cx=0x000000010eb50c00, fval=JS::HandleValue @ 0x000000016fdf4bd0, thisv=JS::HandleValue @ 0x000000016fdf4bc8, args=0x000000016fdf4c50, rval=JS::MutableHandleValue @ 0x000000016fdf4bc0, reason=Call) at Interpreter.cpp:604:8
    frame #25: 0x000000028cbdbe88 XUL`JS::Call(cx=0x000000010eb50c00, thisv=Handle<JS::Value> @ 0x000000016fdf4c48, fval=Handle<JS::Value> @ 0x000000016fdf4c40, args=0x000000016fdf4dd8, rval=MutableHandle<JS::Value> @ 0x000000016fdf4c38) at CallAndConstruct.cpp:117:10
    frame #26: 0x00000002853fda3c XUL`mozilla::dom::EventListener::HandleEvent(this=0x0000000125ac2940, cx=0x000000016fdf5170, aThisVal=Handle<JS::Value> @ 0x000000016fdf4e68, event=0x000000010b85bb20, aRv=0x000000016fdf5200) at EventListenerBinding.cpp:62:8
    frame #27: 0x0000000286015f8c XUL`void mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>(this=0x0000000125ac2940, thisVal=0x000000016fdf5250, event=0x000000010b85bb20, aRv=0x000000016fdf5200, aExecutionReason="EventListener.handleEvent", aExceptionHandling=eReportExceptions, aRealm=0x0000000000000000) at EventListenerBinding.h:65:12
    frame #28: 0x0000000286015b64 XUL`mozilla::EventListenerManager::HandleEventSubType(this=0x000000012ce73680, aListener=0x0000000160e3ec88, aDOMEvent=0x000000010b85bb20, aCurrentTarget=0x0000000160c1ea00) at EventListenerManager.cpp:1310:43
    frame #29: 0x00000002860168f0 XUL`mozilla::EventListenerManager::HandleEventInternal(this=0x000000012ce73680, aPresContext=0x0000000160149c00, aEvent=0x0000000130698e80, aDOMEvent=0x000000016fdf5ce8, aCurrentTarget=0x0000000160c1ea00, aEventStatus=0x000000016fdf5cf0, aItemInShadowTree=false) at EventListenerManager.cpp:1506:17
    frame #30: 0x0000000286044a60 XUL`mozilla::EventListenerManager::HandleEvent(this=0x000000012ce73680, aPresContext=0x0000000160149c00, aEvent=0x0000000130698e80, aDOMEvent=0x000000016fdf5ce8, aCurrentTarget=0x0000000160c1ea00, aEventStatus=0x000000016fdf5cf0, aItemInShadowTree=false) at EventListenerManager.h:395:5
    frame #31: 0x0000000286009854 XUL`mozilla::EventTargetChainItem::HandleEvent(this=0x00000001303540f8, aVisitor=0x000000016fdf5cd8, aCd=0x000000016fdf5d48) at EventDispatcher.cpp:348:17
    frame #32: 0x0000000286008e4c XUL`mozilla::EventTargetChainItem::HandleEventTargetChain(aChain=0x000000016fdf5d40, aVisitor=0x000000016fdf5cd8, aCallback=0x0000000000000000, aCd=0x000000016fdf5d48) at EventDispatcher.cpp:586:14
    frame #33: 0x000000028600b9fc XUL`mozilla::EventDispatcher::Dispatch(aTarget=0x00000001229b0940, aPresContext=0x0000000160149c00, aEvent=0x0000000130698e80, aDOMEvent=0x000000010b85bb20, aEventStatus=0x000000016fdf6154, aCallback=0x0000000000000000, aTargets=0x0000000000000000) at EventDispatcher.cpp:1119:11
    frame #34: 0x000000028600dd04 XUL`mozilla::EventDispatcher::DispatchDOMEvent(aTarget=0x00000001229b0940, aEvent=0x0000000000000000, aDOMEvent=0x000000010b85bb20, aPresContext=0x0000000160149c00, aEventStatus=0x000000016fdf6154) at EventDispatcher.cpp:1236:12
    frame #35: 0x000000028407ffb4 XUL`nsINode::DispatchEvent(this=0x00000001229b0940, aEvent=0x000000010b85bb20, aCallerType=System, aRv=0x000000016fdf6230) at nsINode.cpp:1366:17
    frame #36: 0x000000028543975c XUL`mozilla::dom::EventTarget_Binding::dispatchEvent(cx_=0x000000010eb50c00, obj=Handle<JSObject *> @ 0x000000016fdf6218, void_self=0x00000001229b0940, args=0x000000016fdf6380) at EventTargetBinding.cpp:841:36
    frame #37: 0x000000028570f4bc XUL`bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::MaybeCrossOriginObjectThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(cx=0x000000010eb50c00, argc=1, vp=0x0000000113e13098) at BindingUtils.cpp:3285:13
    frame #38: 0x000000028ca4fee0 XUL`CallJSNative(cx=0x000000010eb50c00, native=(XUL`bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::MaybeCrossOriginObjectThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) at BindingUtils.cpp:3259), reason=Call, args=0x000000016fdf9a40)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) at Interpreter.cpp:417:13
    frame #39: 0x000000028ca4fa00 XUL`js::InternalCallOrConstruct(cx=0x000000010eb50c00, args=0x000000016fdf9a40, construct=NO_CONSTRUCT, reason=Call) at Interpreter.cpp:505:12
    frame #40: 0x000000028ca50650 XUL`InternalCall(cx=0x000000010eb50c00, args=0x000000016fdf9a40, reason=Call) at Interpreter.cpp:572:10
    frame #41: 0x000000028ca504a8 XUL`js::CallFromStack(cx=0x000000010eb50c00, args=0x000000016fdf9a40, reason=Call) at Interpreter.cpp:577:10
    frame #42: 0x000000028ca44e34 XUL`Interpret(cx=0x000000010eb50c00, state=0x000000016fdfa7e8) at Interpreter.cpp:3325:16
    frame #43: 0x000000028ca39c5c XUL`js::RunScript(cx=0x000000010eb50c00, state=0x000000016fdfa7e8) at Interpreter.cpp:389:13
    frame #44: 0x000000028ca4fbf8 XUL`js::InternalCallOrConstruct(cx=0x000000010eb50c00, args=0x000000016fdfa9a0, construct=NO_CONSTRUCT, reason=Call) at Interpreter.cpp:537:13
    frame #45: 0x000000028ca50650 XUL`InternalCall(cx=0x000000010eb50c00, args=0x000000016fdfa9a0, reason=Call) at Interpreter.cpp:572:10
    frame #46: 0x000000028ca507f0 XUL`js::Call(cx=0x000000010eb50c00, fval=JS::HandleValue @ 0x000000016fdfa920, thisv=JS::HandleValue @ 0x000000016fdfa918, args=0x000000016fdfa9a0, rval=JS::MutableHandleValue @ 0x000000016fdfa910, reason=Call) at Interpreter.cpp:604:8
    frame #47: 0x000000028cbdbe88 XUL`JS::Call(cx=0x000000010eb50c00, thisv=Handle<JS::Value> @ 0x000000016fdfa998, fval=Handle<JS::Value> @ 0x000000016fdfa990, args=0x000000016fdfab28, rval=MutableHandle<JS::Value> @ 0x000000016fdfa988) at CallAndConstruct.cpp:117:10
    frame #48: 0x00000002853fda3c XUL`mozilla::dom::EventListener::HandleEvent(this=0x00000001198887c0, cx=0x000000016fdfaec0, aThisVal=Handle<JS::Value> @ 0x000000016fdfabb8, event=0x0000000130698df0, aRv=0x000000016fdfaf50) at EventListenerBinding.cpp:62:8
    frame #49: 0x0000000286015f8c XUL`void mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>(this=0x00000001198887c0, thisVal=0x000000016fdfafa0, event=0x0000000130698df0, aRv=0x000000016fdfaf50, aExecutionReason="EventListener.handleEvent", aExceptionHandling=eReportExceptions, aRealm=0x0000000000000000) at EventListenerBinding.h:65:12
    frame #50: 0x0000000286015b64 XUL`mozilla::EventListenerManager::HandleEventSubType(this=0x0000000130894780, aListener=0x0000000123ba6c48, aDOMEvent=0x0000000130698df0, aCurrentTarget=0x00000001229b0940) at EventListenerManager.cpp:1310:43
    frame #51: 0x00000002860168f0 XUL`mozilla::EventListenerManager::HandleEventInternal(this=0x0000000130894780, aPresContext=0x0000000160149c00, aEvent=0x000000016fdfc328, aDOMEvent=0x000000016fdfba38, aCurrentTarget=0x00000001229b0940, aEventStatus=0x000000016fdfba40, aItemInShadowTree=false) at EventListenerManager.cpp:1506:17
    frame #52: 0x0000000286044a60 XUL`mozilla::EventListenerManager::HandleEvent(this=0x0000000130894780, aPresContext=0x0000000160149c00, aEvent=0x000000016fdfc328, aDOMEvent=0x000000016fdfba38, aCurrentTarget=0x00000001229b0940, aEventStatus=0x000000016fdfba40, aItemInShadowTree=false) at EventListenerManager.h:395:5
    frame #53: 0x0000000286009854 XUL`mozilla::EventTargetChainItem::HandleEvent(this=0x000000011557c0f8, aVisitor=0x000000016fdfba28, aCd=0x000000016fdfba98) at EventDispatcher.cpp:348:17
    frame #54: 0x0000000286008e4c XUL`mozilla::EventTargetChainItem::HandleEventTargetChain(aChain=0x000000016fdfba90, aVisitor=0x000000016fdfba28, aCallback=0x000000016fdfbfd0, aCd=0x000000016fdfba98) at EventDispatcher.cpp:586:14
    frame #55: 0x000000028600b9fc XUL`mozilla::EventDispatcher::Dispatch(aTarget=0x000000012290ca60, aPresContext=0x0000000160149c00, aEvent=0x000000016fdfc328, aDOMEvent=0x0000000000000000, aEventStatus=0x000000016fdfc324, aCallback=0x000000016fdfbfd0, aTargets=0x0000000000000000) at EventDispatcher.cpp:1119:11
    frame #56: 0x0000000288ee29b8 XUL`mozilla::PresShell::EventHandler::DispatchEventToDOM(this=0x000000016fdfc270, aEvent=0x000000016fdfc328, aEventStatus=0x000000016fdfc324, aEventCB=0x000000016fdfbfd0) at PresShell.cpp:8653:7
    frame #57: 0x0000000288ee17bc XUL`mozilla::PresShell::EventHandler::DispatchEvent(this=0x000000016fdfc270, aEventStateManager=0x0000000123fd6d00, aEvent=0x000000016fdfc328, aTouchIsNew=false, aEventStatus=0x000000016fdfc324, aOverrideClickTarget=0x0000000000000000) at PresShell.cpp:8225:7
    frame #58: 0x0000000288edc264 XUL`mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(this=0x000000016fdfc270, aEvent=0x000000016fdfc328, aEventStatus=0x000000016fdfc324, aIsHandlingNativeEvent=false, aOverrideClickTarget=0x0000000000000000) at PresShell.cpp:8157:17
    frame #59: 0x0000000288edfeac XUL`mozilla::PresShell::EventHandler::HandleEventWithTarget(this=0x000000016fdfc270, aEvent=0x000000016fdfc328, aNewEventFrame=0x00000001197a68e8, aNewEventContent=0x000000012290ca60, aEventStatus=0x000000016fdfc324, aIsHandlingNativeEvent=false, aTargetContent=0x0000000000000000, aOverrideClickTarget=0x0000000000000000) at PresShell.cpp:8064:17
    frame #60: 0x0000000283b4bf4c XUL`mozilla::PresShell::HandleEventWithTarget(this=0x0000000130c68000, aEvent=0x000000016fdfc328, aFrame=0x00000001197a68e8, aContent=0x000000012290ca60, aEventStatus=0x000000016fdfc324, aIsHandlingNativeEvent=false, aTargetContent=0x0000000000000000, aOverrideClickTarget=0x0000000000000000) at PresShell.h:664:25
    frame #61: 0x0000000285f9b658 XUL`mozilla::EventStateManager::InitAndDispatchClickEvent(aMouseUpEvent=0x000000016fdfd5f8, aStatus=0x000000016fdfc5f4, aMessage=eMouseClick, aPresShell=0x0000000130c68000, aMouseUpContent=0x000000012290ca60, aCurrentTarget=AutoWeakFrame @ 0x000000016fdfc530, aNoContentDispatch=false, aOverrideClickTarget=0x0000000000000000) at EventStateManager.cpp:5259:29
    frame #62: 0x0000000285f9ba9c XUL`mozilla::EventStateManager::DispatchClickEvents(this=0x0000000123fd6d00, aPresShell=0x0000000130c68000, aMouseUpEvent=0x000000016fdfd5f8, aStatus=0x000000016fdfc5f4, aClickTarget=0x000000012290ca60, aOverrideClickTarget=0x0000000000000000) at EventStateManager.cpp:5361:17
    frame #63: 0x0000000285f9752c XUL`mozilla::EventStateManager::PostHandleMouseUp(this=0x0000000123fd6d00, aMouseUpEvent=0x000000016fdfd5f8, aStatus=0x000000016fdfd0a4, aOverrideClickTarget=0x0000000000000000) at EventStateManager.cpp:5304:17
    frame #64: 0x0000000285f95d70 XUL`mozilla::EventStateManager::PostHandleEvent(this=0x0000000123fd6d00, aPresContext=0x0000000160149c00, aEvent=0x000000016fdfd5f8, aTargetFrame=0x0000000000000000, aStatus=0x000000016fdfd0a4, aOverrideClickTarget=0x0000000000000000) at EventStateManager.cpp:3578:18
    frame #65: 0x0000000288ee1864 XUL`mozilla::PresShell::EventHandler::DispatchEvent(this=0x000000016fdfce80, aEventStateManager=0x0000000123fd6d00, aEvent=0x000000016fdfd5f8, aTouchIsNew=false, aEventStatus=0x000000016fdfd0a4, aOverrideClickTarget=0x0000000000000000) at PresShell.cpp:8239:30
    frame #66: 0x0000000288edc264 XUL`mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(this=0x000000016fdfce80, aEvent=0x000000016fdfd5f8, aEventStatus=0x000000016fdfd0a4, aIsHandlingNativeEvent=true, aOverrideClickTarget=0x0000000000000000) at PresShell.cpp:8157:17
    frame #67: 0x0000000288edbdf4 XUL`mozilla::PresShell::EventHandler::HandleEventUsingCoordinates(this=0x000000016fdfcf90, aFrameForPresShell=0x000000011977c020, aGUIEvent=0x000000016fdfd5f8, aEventStatus=0x000000016fdfd0a4, aDontRetargetEvents=false) at PresShell.cpp:7106:30
    frame #68: 0x0000000288eda744 XUL`mozilla::PresShell::EventHandler::HandleEvent(this=0x000000016fdfcf90, aFrameForPresShell=0x000000011977c020, aGUIEvent=0x000000016fdfd5f8, aDontRetargetEvents=false, aEventStatus=0x000000016fdfd0a4) at PresShell.cpp:6909:12
    frame #69: 0x0000000288ed9908 XUL`mozilla::PresShell::HandleEvent(this=0x0000000115ab2000, aFrameForPresShell=0x000000011977c020, aGUIEvent=0x000000016fdfd5f8, aDontRetargetEvents=false, aEventStatus=0x000000016fdfd0a4) at PresShell.cpp:6852:23
    frame #70: 0x000000028890fbf4 XUL`nsViewManager::DispatchEvent(this=0x00000001213f7100, aEvent=0x000000016fdfd5f8, aView=0x00000001157f9500, aStatus=0x000000016fdfd0a4) at nsViewManager.cpp:685:18
    frame #71: 0x000000028890f958 XUL`nsView::HandleEvent(this=0x00000001157f9500, aEvent=0x000000016fdfd5f8, aUseAttachedEvents=false) at nsView.cpp:1128:9
    frame #72: 0x0000000288a283b0 XUL`nsChildView::DispatchEvent(this=0x0000000122c82200, event=0x000000016fdfd5f8, aStatus=0x000000016fdfd340) at nsChildView.mm:1273:37
    frame #73: 0x00000002889276ac XUL`nsBaseWidget::ProcessUntransformedAPZEvent(this=0x0000000122c82200, aEvent=0x000000016fdfd5f8, aApzResult=0x000000016fdfd4a0) at nsBaseWidget.cpp:886:3
    frame #74: 0x0000000288928614 XUL`nsBaseWidget::DispatchInputEvent(this=0x0000000122c82200, aEvent=0x000000016fdfd5f8) at nsBaseWidget.cpp:1065:31
    frame #75: 0x0000000288a30a24 XUL`-[ChildView mouseUp:](self=0x0000000122c83400, _cmd="mouseUp:", theEvent=0x0000000130b634c0) at nsChildView.mm:2854:41
    frame #76: 0x00000001a0940738 AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2020
    frame #77: 0x00000001a093fd80 AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 284
    frame #78: 0x0000000288ab8e14 XUL`-[ToolbarWindow sendEvent:](self=0x000000010efa4400, _cmd="sendEvent:", anEvent=0x0000000130b634c0) at nsCocoaWindow.mm:3933:3
    frame #79: 0x00000001a093efac AppKit`-[NSApplication(NSEvent) sendEvent:] + 1924
    frame #80: 0x0000000288a8ebf0 XUL`-[GeckoNSApplication sendEvent:](self=0x0000000100470a70, _cmd="sendEvent:", anEvent=0x0000000130b634c0) at nsAppShell.mm:165:3
    frame #81: 0x00000001a0b903a0 AppKit`-[NSApplication _handleEvent:] + 60
    frame #82: 0x00000001a080462c AppKit`-[NSApplication run] + 500
    frame #83: 0x0000000288a90d70 XUL`nsAppShell::Run(this=0x000000010b8358d0) at nsAppShell.mm:801:5
    frame #84: 0x000000028c611f9c XUL`nsAppStartup::Run(this=0x000000010049f880) at nsAppStartup.cpp:295:30
    frame #85: 0x000000028c827234 XUL`XREMain::XRE_mainRun(this=0x000000016fdfeb68) at nsAppRunner.cpp:5700:22
    frame #86: 0x000000028c8281c4 XUL`XREMain::XRE_main(this=0x000000016fdfeb68, argc=5, argv=0x000000016fdff4f8, aConfig=0x000000016fdfed10) at nsAppRunner.cpp:5894:8
    frame #87: 0x000000028c828788 XUL`XRE_main(argc=5, argv=0x000000016fdff4f8, aConfig=0x000000016fdfed10) at nsAppRunner.cpp:5962:21
    frame #88: 0x000000028c84499c XUL`mozilla::BootstrapImpl::XRE_main(this=0x00000001004080e0, argc=5, argv=0x000000016fdff4f8, aConfig=0x000000016fdfed10) at Bootstrap.cpp:45:12
    frame #89: 0x0000000100001100 firefox`do_main(argc=5, argv=0x000000016fdff4f8, envp=0x000000016fdff528) at nsBrowserApp.cpp:227:22
    frame #90: 0x0000000100000a28 firefox`main(argc=5, argv=0x000000016fdff4f8, envp=0x000000016fdff528) at nsBrowserApp.cpp:414:16
    frame #91: 0x00000002235d8da8 dyld`start + 2376
Severity: -- → S2
Priority: -- → P2

I just tested with my Intel local build (in lldb) and found that objc_addExceptionHandler gets hit when I choose "print using the system dialog", but neither libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::step() nor libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE() gets hit. So none of the libunwind code gets exercised by my Intel local build. I'm not sure why.

Edit: Oops, libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step() does get hit. I forgot to change Registers_arm64 in its definition to Registers_x86_64. So it's only libunwind::CFI_Parser<libunwind::LocalAddressSpace>::decodeFDE() that doesn't.

Here's the source code for UnwindCursor<A, R>::step():

template <typename A, typename R>
int UnwindCursor<A, R>::step() {
  // Bottom of stack is defined is when unwind info cannot be found.
  if (_unwindInfoMissing)
    return UNW_STEP_END;

  // Use unwinding info to modify register set as if function returned.
  int result;
#if defined(_LIBUNWIND_SUPPORT_COMPACT_UNWIND)
  result = this->stepWithCompactEncoding();
#elif defined(_LIBUNWIND_SUPPORT_SEH_UNWIND)
  result = this->stepWithSEHData();
#elif defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
  result = this->stepWithDwarfFDE();
#elif defined(_LIBUNWIND_ARM_EHABI)
  result = this->stepWithEHABI();
#else
  #error Need _LIBUNWIND_SUPPORT_COMPACT_UNWIND or \
              _LIBUNWIND_SUPPORT_SEH_UNWIND or \
              _LIBUNWIND_SUPPORT_DWARF_UNWIND or \
              _LIBUNWIND_ARM_EHABI
#endif

  // update info based on new PC
  if (result == UNW_STEP_SUCCESS) {
    this->setInfoBasedOnIPRegister(true);
    if (_unwindInfoMissing)
      return UNW_STEP_END;
  }

  return result;
}

From the machine code I'm able to tell that _LIBUNWIND_SUPPORT_DWARF_UNWIND is defined on Intel builds. Looking at DwarfInstructions<A, R>::stepWithDwarf(), you can see that it calls CFI_Parser<A>::decodeFDE() unconditionally. Since it's never called, UnwindCursor<A, R>::step() must be returning early because _unwindInfoMissing is true.

So the code that might crash on Intel builds isn't called because "Dwarf unwind info" is missing.

I'm beginning to suspect this is an Apple bug, introduced in macOS 13 Beta 4 (build 22A5311f). Still though, it's possible there's something wrong with the "ARM unwind info" that isn't missing in local builds.

I just got exactly the same crash using a local build on an Apple Silicon machine running macOS 12.5. So this crash isn't just on macOS 13.

I'll try doing local builds on my Apple Silicon box with other versions of macOS. Next up is macOS 11.6.8. Not sure how I'll be able to test the older versions.

Next up is macOS 11.6.8.

Same thing there. I get the same crash using a local build made on macOS 11.6.8 (on my Apple Silicon machine).

Thanks for the debugging, Steven. I'm updating the bug to indicate it's not a new macOS 13 issue.

No longer blocks: 1773708
Summary: [macOS 13] Local Nightly builds crash when displaying system print dialog → Local Nightly builds crash when displaying system print dialog on Apple Silicon
Crash Signature: [@ libunwind::CFI_Parser<T>::decodeFDE ]

Hello,

We managed to reproduce this issue on a MacBook PRO (16-inch, 2021) with Apple M1 PRO Chip with FF Nightly 106.0a1(2022-09-05).
We tried to retrieve a pushlog_URL but unable to find any bad build while using the mozregression_ui tool(went as far back as the beginning of the year)

https://crash-stats.mozilla.org/report/index/98441244-2351-4311-a5a2-5c1040220906

Ah, but this is now fixed in today's mozilla-central nightly. The "deregression range" for this is as follows:

Last bad build: http://archive.mozilla.org/pub/firefox/nightly/2022/09/2022-09-07-17-41-50-mozilla-central/firefox-106.0a1.en-US.mac.dmg
First good build: http://archive.mozilla.org/pub/firefox/nightly/2022/09/2022-09-08-09-28-10-mozilla-central/firefox-106.0a1.en-US.mac.dmg

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=49a271c42001&tochange=21386acd44738780c060ee8070d29f7eefc9af5c

So it's almost certain that the patch for bug 1788837 triggered this behavior. It was landed in the first range (from comment #10) and backed out in the second (from this comment).

So it's using lld to build the Mozilla tree (as opposed to ld64) that triggers this bug's crashes.

Gabrielle, do you have any idea what's going on here?

Flags: needinfo?(gsvelto)

Note that lld has been used all along in macOS local builds -- to which these crashes were limited before bug 1788837 and to which they are now again limited, presumably.

Summary: Local Nightly builds crash when displaying system print dialog on Apple Silicon → Local Nightly builds crash in libunwind.dylib when displaying system print dialog on Apple Silicon

No clue, maybe :glandium might be able to help.

Flags: needinfo?(gsvelto)

I thought turning off unwind tables (with -fno-unwind-tables) might stop these crashes happening in a local build (on Apple Silicon hardware). No, it doesn't.

The only way I found to turn off unwind tables is with the following patch:

diff --git a/build/moz.configure/toolchain.configure b/build/moz.configure/toolchain.configure
--- a/build/moz.configure/toolchain.configure
+++ b/build/moz.configure/toolchain.configure
@@ -2277,7 +2277,7 @@ def frame_pointer_flags(compiler):
             disable=["-Oy"],
         )
     return namespace(
-        enable=["-fno-omit-frame-pointer", "-funwind-tables"],
+        enable=["-fno-omit-frame-pointer", "-fno-unwind-tables"],
         disable=["-fomit-frame-pointer", "-funwind-tables"],
     )

These crashes are caused by what appears to be a bug in lld (more about this later). Using ld64 instead of lld fixes them in current mozilla-central local builds.

My analysis in comment #3 above was wrong. Both _LIBUNWIND_SUPPORT_COMPACT_UNWIND and _LIBUNWIND_SUPPORT_DWARF_UNWIND are defined on both Intel and Apple Silicon. And the unwind information isn't missing on Intel Macs. Both kinds are present (in XUL) on both platforms. But for some reason the Dwarf information isn't used (in this bug's context) on Intel Macs (where each "step" up the call frame takes place here.) But even if that weren't true, these crashes wouldn't happen on Intel Macs. The bug in lld only effects objects linked on Apple Silicon Macs.

This bug's crashes happen during calls (in system code) to libobjc.A.dylib's objc_addExceptionHandler. This calls findHandler, which attempts to find existing exception handlers by using the current instruction pointer to walk up the call stack. This bug's crashes happen during one of the "steps" up the call stack.

Specifically they happen when libunwind.dylib is trying to decode a Dwarf "Frame Description Entry", at the following line:

pint_t cfiLength = (pint_t)addressSpace.get32(p);

This is because decodeFDE() is being called with a zero fdeStart parameter. (Note that this parameter is in the $X0 register. The addressSpace parameter is compiled away because it always points to the same, static object.)

The value of fdeStart comes from the lowest 24 bits of _info.format here. _info.format ultimately gets set (here) to an "encoding" from the compact unwind section (__unwind_info) of the __TEXT segment.

The 4 bits at 0x0F000000 determine what kind of unwind information the encoding refers to. 0x03000000 indicates Dwarf information, which is actually in another section (__eh_frame) of the __TEXT segment. In this case the lowest 24 bits are (or should be) an offset into the __eh_frame section. (See https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/include/mach-o/compact_unwind_encoding.h for more information.)

Here are some examples of Dwarf "encodings" from XUL's __unwind_info section created by ld64 on an Apple Silicon machine (from the output of objdump -u XUL):

[787]: function offset=0x000bb480, encoding[125]=0x03000014
[757]: function offset=0x00255bb8, encoding[126]=0x03000060
[758]: function offset=0x00255c28, encoding[125]=0x030000a8

And here are some from XULs __unwind_info section created by lld:

[824]: function offset=0x000bb480, encoding[24]=0x03000000
[793]: function offset=0x00255bd8, encoding[24]=0x03000000
[962]: function offset=0x0030ab9c, encoding[24]=0x03000000

Notice that the offsets from lld are all 0. This is the bug in lld, and the reason these crashes happen.

Regressed by: 1788837
See Also: 1788837 →

:glandium, since you are the author of the regressor, bug 1788837, could you take a look?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mh+mozilla)

The lld bug I described in comment #16 is fixed in the latest LLVM code (available by doing git clone https://github.com/llvm/llvm-project). I'll try the 15.0.0 and 14.0.6 releases, to find out if the fix is also there.

To do my test, I built lld according to the instructions at https://lld.llvm.org/, copied its binary to ~/.mozbuild/clang/bin, then rebuilt the mozilla-central tree.

It seems Mozilla is currently using LLVM version 14.0.5. I don't know if any of it has been customized.

lld from LLVM 14.0.6 has the bug. lld from LLVM 15.0.0 doesn't.

So presumably the best way to fix this bug will be to upgrade to LLVM 15.0.0 in Mozilla's build toolkit (what gets installed to ~/.mozbuild). As a fallback, Mozilla could always use ld64 (even for local builds) on Apple Silicon Macs.

We're going to upgrade to llvm 15 soon.

Flags: needinfo?(mh+mozilla)

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

Fixed by bug 1784202, presumably.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Assignee: nobody → mh+mozilla
status-firefox107: --- → unaffected
status-firefox108: --- → fixed
status-firefox-esr102: --- → unaffected
Depends on: clang-15
Target Milestone: --- → 108 Branch
You need to log in before you can comment on or make changes to this bug.