1574521 - Local builds on macOS 10.14 crash on startup (unless a pre-10.14 SDK is specified in the mozconfig)

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[David Burns :automatedtester]

With the latest checkout (e0aed6c21c272812a420888614c2925e39f6712b) of central and doing a clobber I am not able to get firefox to run

I get

davidburns in ~/development/mozilla-unified(ruby-2.6.0) λ ./mach run
 0:00.38 /Users/davidburns/development/mozilla-unified/obj-x86_64-apple-darwin18.6.0/dist/Nightly.app/Contents/MacOS/firefox -no-remote -foreground -profile /Users/davidburns/development/mozilla-unified/obj-x86_64-apple-darwin18.6.0/tmp/profile-default
1565969151216	[e-mail]	WARN	Loading extension '[e-mail]': Reading manifest: Invalid extension permission: mozillaAddons
1565969151217	[e-mail]	WARN	Loading extension '[e-mail]': Reading manifest: Invalid extension permission: telemetry
1565969151217	[e-mail]	WARN	Loading extension '[e-mail]': Reading manifest: Invalid extension permission: resource://pdf.js/
1565969151217	[e-mail]	WARN	Loading extension '[e-mail]': Reading manifest: Invalid extension permission: about:reader*
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=0.26562) %

Comment 1

[Markus Stange [:mstange]]

I am worried that I put in a release assert in bug 1491442 that happens to fire on startup for local builds that are built with the 10.14 SDK. I am building locally with the 10.14 SDK now, trying to reproduce it.

Comment 2

[Markus Stange [:mstange]]

It's not a release assert, it's a null dereference:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Note:        EXC_CORPSE_NOTIFY
​
Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [37218]
​
VM Regions Near 0x10:
--> 
    __TEXT                 0000000109c43000-0000000109c45000 [    8K] r-x/rwx SM=COW  /Users/USER/*/Nightly.app/Contents/MacOS/firefox
​
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_pthread.dylib       	0x00007fff6b9e3e0d pthread_mutex_trylock + 0
1   libmozglue.dylib              	0x0000000109c84f2e mozilla::detail::MutexImpl::lock() + 46 (Mutex_posix.cpp:134)
2   XUL                           	0x0000000110a99e30 mozilla::layers::NativeLayerRootCA::ApplyChanges() + 32 (NativeLayerCA.mm:79)
3   XUL                           	0x00000001124acfb1 nsChildView::HandleMainThreadCATransaction() + 369 (nsChildView.mm:1536)
4   com.apple.AppKit              	0x00007fff3d051301 _NSViewUpdateLayer + 45
5   com.apple.AppKit              	0x00007fff3d050d1d -[_NSViewBackingLayer display] + 505
6   com.apple.QuartzCore          	0x00007fff4a340055 CA::Layer::display_if_needed(CA::Transaction*) + 627
7   com.apple.QuartzCore          	0x00007fff4a32e27a CA::Context::commit_transaction(CA::Transaction*) + 342
8   com.apple.QuartzCore          	0x00007fff4a32d8c2 CA::Transaction::commit() + 588
9   com.apple.AppKit              	0x00007fff3d047a4d __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 274
10  com.apple.CoreFoundation      	0x00007fff3f91e928 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
11  com.apple.CoreFoundation      	0x00007fff3f91e85d __CFRunLoopDoObservers + 451
12  com.apple.CoreFoundation      	0x00007fff3f8c0f80 __CFRunLoopRun + 1136
13  com.apple.CoreFoundation      	0x00007fff3f8c08be CFRunLoopRunSpecific + 455
14  com.apple.HIToolbox           	0x00007fff3ebac96b RunCurrentEventLoopInMode + 292
15  com.apple.HIToolbox           	0x00007fff3ebac5ad ReceiveNextEventCommon + 355
16  com.apple.HIToolbox           	0x00007fff3ebac436 _BlockUntilNextEventMatchingListInModeWithFilter + 64
17  com.apple.AppKit              	0x00007fff3cf46987 _DPSNextEvent + 965
18  com.apple.AppKit              	0x00007fff3cf4571f -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
19  XUL                           	0x0000000112500a8b -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 219
20  com.apple.AppKit              	0x00007fff3cf3f83c -[NSApplication run] + 699
21  XUL                           	0x0000000112501c79 nsAppShell::Run() + 281 (nsAppShell.mm:708)
22  XUL                           	0x00000001137aa10e nsAppStartup::Run() + 62 (nsAppStartup.cpp:277)
23  XUL                           	0x00000001138d70e0 XREMain::XRE_mainRun() + 2192 (nsAppRunner.cpp:4631)
24  XUL                           	0x00000001138d7b62 XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) + 1602 (nsAppRunner.cpp:4766)
25  XUL                           	0x00000001138d804b XRE_main(int, char**, mozilla::BootstrapConfig const&) + 155 (nsAppRunner.cpp:4847)
26  org.mozilla.nightly           	0x0000000109c4403b main + 939
27  libdyld.dylib                 	0x00007fff6b7ef3d5 start + 1

wantsUpdateLayer expects to only be called when the CoreAnimation pref is set to true, but in builds with the 10.14 SDK, it gets called even if the pref is set to false, so wantsUpdateLayer returns YES, updateLayer gets called, and runs into objects that are unexpectedly null.

I'll put up a workaround in a second.

Comment 3

[Markus Stange [:mstange]]

Attachment: Bug 1574521 - Make sure updateLayer is only called when the CoreAnimation pref is set. r=jrmuizel

updateLayer expects some objects to be non-null which are only initialized when the pref is set.
But in builds that were compiled with the 10.14 SDK, all NSViews are layer-backed by default, so
wantspdateLayer gets called, and returning YES from that unconditionally will cause updateLayer
to be called.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/19cdc92b399f
Make sure updateLayer is only called when the CoreAnimation pref is set. r=jrmuizel a=Aryx

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/19cdc92b399f