1683579 - Firefox ESR 78 Crashes on Apple Silicon M1 Machine

Status: RESOLVED DUPLICATE of bug 1659057

(Core :: Security: Process Sandboxing, defect, P1)

Description

[Haik Aftandilian [:haik]]

After starting Firefox ESR 78 and visiting cnn.com, the browser crashes after a few seconds. Running via the command line with the crash reporter disabled I hit a content crash which indicates this may be a content crash triggering a crash in crash reporting. We'll need another bug to address the crash reporter issue, but it could be a duplicate of bug 1624467.

Browser crash reported by :gcox:
https://crash-stats.mozilla.org/report/index/6a03767e-27dd-4ba4-a594-598d70201220

Content crash:

$ MOZ_CRASHREPORTER_DISABLE=1 /Applications/FirefoxESR.app/Contents/MacOS/firefox

(lldb) bt
* thread #45, name = 'MediaPD~oder #1', queue = 'com.Metal.DeviceDispatch', stop reason = signal SIGABRT
  * frame #0: 0x00007fff20343462 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff20371610 libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007fff202c4720 libsystem_c.dylib`abort + 120
    frame #3: 0x000000017dc9394e AGXMetal13_3`___lldb_unnamed_symbol7$$AGXMetal13_3 + 13982
    frame #4: 0x000000017dcc18ed AGXMetal13_3`___lldb_unnamed_symbol496$$AGXMetal13_3 + 45
    frame #5: 0x00007fff28578bef Metal`-[MTLIOAccelService initWithAcceleratorPort:] + 382
    frame #6: 0x00007fff28578a4b Metal`+[MTLIOAccelService registerService:] + 143
    frame #7: 0x00007fff201c57c7 libdispatch.dylib`_dispatch_client_callout + 8
    frame #8: 0x00007fff201d2605 libdispatch.dylib`_dispatch_lane_barrier_sync_invoke_and_complete + 60
    frame #9: 0x00007fff28628fd2 Metal`MTLIOAccelServiceRegisterService + 71
    frame #10: 0x00007fff285788b6 Metal`+[MTLIOAccelDevice registerDevices] + 146
    frame #11: 0x00007fff285a3618 Metal`invocation function for block in MTLDeviceArrayInitialize() + 1185
    frame #12: 0x00007fff201c57c7 libdispatch.dylib`_dispatch_client_callout + 8
    frame #13: 0x00007fff201c696b libdispatch.dylib`_dispatch_once_callout + 20
    frame #14: 0x00007fff285a0716 Metal`MTLCopyAllDevicesWithObserver + 249
    frame #15: 0x00007fff2be3a498 VideoToolbox`___lldb_unnamed_symbol819$$VideoToolbox + 169
    frame #16: 0x00007fff2036e21f libsystem_pthread.dylib`__pthread_once_handler + 65
    frame #17: 0x00007fff203b3646 libsystem_platform.dylib`_os_once_callout + 18
    frame #18: 0x00007fff2036e1cd libsystem_pthread.dylib`pthread_once + 74
    frame #19: 0x00007fff2bd97414 VideoToolbox`VTCopyRenderIDArrayForIORegistryKey + 115
    frame #20: 0x00007fff2be3e1f4 VideoToolbox`___lldb_unnamed_symbol835$$VideoToolbox + 346
    frame #21: 0x00007fff2be3cbee VideoToolbox`___lldb_unnamed_symbol831$$VideoToolbox + 2375
    frame #22: 0x00007fff2bd97d7c VideoToolbox`VTDecompressionSessionCreateWithOptions + 1577
    frame #23: 0x00007fff2bda7eb9 VideoToolbox`VTDecompressionSessionCreate + 20
    frame #24: 0x000000010c3ee4e9 XUL`___lldb_unnamed_symbol146527$$XUL + 361
    frame #25: 0x000000010c3ee322 XUL`___lldb_unnamed_symbol146526$$XUL + 50
    frame #26: 0x000000010c40bd6c XUL`___lldb_unnamed_symbol146830$$XUL + 124
    frame #27: 0x0000000108b8e3b2 XUL`___lldb_unnamed_symbol4491$$XUL + 546
    frame #28: 0x0000000108bb12f5 XUL`___lldb_unnamed_symbol5002$$XUL + 1589
    frame #29: 0x0000000108ba87d2 XUL`___lldb_unnamed_symbol4908$$XUL + 1986
    frame #30: 0x0000000108bae51c XUL`___lldb_unnamed_symbol4974$$XUL + 60
    frame #31: 0x00000001093c3f48 XUL`___lldb_unnamed_symbol32747$$XUL + 296
    frame #32: 0x0000000109350bce XUL`___lldb_unnamed_symbol31172$$XUL + 110
    frame #33: 0x0000000108ba52aa XUL`___lldb_unnamed_symbol4871$$XUL + 554
    frame #34: 0x000000010844b711 libnss3.dylib`___lldb_unnamed_symbol1393$$libnss3.dylib + 305
    frame #35: 0x00007fff20371950 libsystem_pthread.dylib`_pthread_start + 224
    frame #36: 0x00007fff2036d47b libsystem_pthread.dylib`thread_start + 15Ï

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

This is the bottom of our part of the stack:

https://searchfox.org/mozilla-esr78/rev/02e40325a8d5de8b60cba7fddf4ce68ed00f92af/dom/media/platforms/apple/AppleVTDecoder.cpp#495
https://searchfox.org/mozilla-central/rev/8698fade12984b9a6a43a85a287a5f17e8fd4ddf/dom/media/platforms/apple/AppleVTDecoder.cpp#525

I wasn't able to find any obvious (to me) patches for Apple Silicon applied in releases after 78 ESR but the media team would know better :).

Comment 2

[Jean-Yves Avenard [:jya]]

There's been no code change on the VT decoder since the last ESR release.

Sandbox issue perhaps? The VT decoder now runs in the RDD process and changes had to be made to work on the M1 platform.

Comment 3

[Haik Aftandilian [:haik]]

(In reply to Jean-Yves Avenard [:jya] from comment #2)

There's been no code change on the VT decoder since the last ESR release.

Sandbox issue perhaps? The VT decoder now runs in the RDD process and changes had to be made to work on the M1 platform.

You're right. The problem does not reproduce with the content sandbox related. One fix that we'll need is bug 1660045 which has is not in the ESR. I'll take the bug.

Comment 5

[Haik Aftandilian [:haik]]

This is a duplicate of bug 1659057.

Disassembly of the crashing function shows that it calls getSystemMemorySize() before aborting and we see the following message on the console AGX: agxs_util.cpp:355:size_t getSystemMemorySize(): !!! Verification failed: status == 0. Testing with the fix for bug 1659057 ported to ESR78, I could not reproduce the problem.