macOS: Browser source (CEF) crash on CrBrowserMain — EXC_BAD_ACCESS / null write during autorelease pool drain (obs-browser 32.1.2, macOS 26.5.1, Apple Silicon)

Summary

On macOS (Apple Silicon), OBS crashes with EXC_BAD_ACCESS (SIGSEGV) on the CrBrowserMain main thread. The crash happens inside an autorelease pool drain while an NSArray is being deallocated: one of the objects in the array gets a release message sent to it after it is already gone, so the app writes to a null pointer and dies.

I have a scene with Browser sources, and the obs-browser plugin (CEF) is loaded and appears at the top of both crash backtraces. I caught the crash twice within a few minutes, from two different triggers, but both land on the exact same code path.

This looks like a browser-source object (CEF) being released twice / released after it is already freed during Cocoa's autorelease pool cleanup.

Steps to reproduce

I do not have a 100% reliable single click that reproduces it, but I hit it twice in ~6 minutes with these two triggers:

Crash 1 — reordering a source by dragging

1. Have a scene that contains one or more Browser sources.
2. In the Sources list, grab a source and drag it up/down to reorder it.
3. On drop, OBS crashes.

Crash 2 — no drag, idle

1. Same scene with Browser sources loaded.
2. OBS is just running (normal event loop, no drag). It crashed on its own a few minutes after relaunch.

Both crashes are on CrBrowserMain, both are a null write (far: 0x0) during an autorelease pool drain releasing an NSArray, with Chromium Embedded Framework as the top two frames and the failing Objective-C selector being release.

Environment

• OBS Studio: 32.1.2 (24742303888), arm64 native
• macOS: 26.5.1 (25F80)
• Hardware: Apple Silicon (Mac16,10)
• Plugin loaded: com.obsproject.obs-browser (32.1.2) — /Applications/OBS.app/Contents/PlugIns/obs-browser.plugin/Contents/MacOS/obs-browser
• Install: official OBS release build (not self-compiled)

Browser sources in the scene collection (4):

Name	Source
test	local file overlay.html (a static stats overlay)
subscribe alerts	remote page — Streamlabs alert box (https://streamlabs.com/alert-box/...)
good night	local file goodnight.html
be right back	local file brb.html

The only remote/live page is the Streamlabs alert box; the other three are simple local HTML files.

Crash details

Both reports:

• Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000000
• Fault: far: 0x0 esr: 0x92000046 (Data Abort) byte write Translation fault
• Triggering thread: Thread 0 CrBrowserMain, com.apple.main-thread
• Failing selector: release

Crash 1 backtrace (drag trigger) — Thread 0:

0   Chromium Embedded Framework   ... + 17000048
1   Chromium Embedded Framework   ... + 16999480
2   CoreFoundation                ___forwarding___ + 216
3   CoreFoundation                _CF_forwarding_prep_0 + 96
4   CoreFoundation                __RELEASE_OBJECTS_IN_THE_ARRAY__ + 116
5   CoreFoundation                -[__NSArrayM dealloc] + 148
6   libqcocoa.dylib               0x107954000 + 515284
7   libobjc.A.dylib               AutoreleasePoolPage::releaseUntil(objc_object**) + 204
8   libobjc.A.dylib               objc_autoreleasePoolPop + 244
9   CoreFoundation                _CFAutoreleasePoolPop + 32
10  AppKit                        NSCoreDragReceiveMessageProc + 1992
11  HIServices                    CallReceiveMessageCollectionWithMessage + 116
12  HIServices                    DoMultipartDropMessage + 96
13  HIServices                    DoDropMessage + 56
14  HIServices                    DragInApplication + 952
15  HIServices                    CoreDragStartDraggingAsync + 572
16  AppKit                        -[NSCoreDragManager _dragUntilMouseUp:initialEvent:async:] + 1204
...
21  QtGui                         QDragManager::drag(QDrag*) + 368
22  QtGui                         QDrag::exec(QFlags<Qt::DropAction>, Qt::DropAction) + 120
23  QtWidgets                     QAbstractItemView::startDrag(QFlags<Qt::DropAction>) + 576
25  QtWidgets                     QListView::mouseMoveEvent(QMouseEvent*) + 72

Crash 2 backtrace (no drag, idle) — Thread 0:

0   Chromium Embedded Framework   ... + 17000048
1   Chromium Embedded Framework   ... + 16999480
2   CoreFoundation                ___forwarding___ + 216
3   CoreFoundation                _CF_forwarding_prep_0 + 96
4   CoreFoundation                __RELEASE_OBJECTS_IN_THE_ARRAY__ + 116
5   CoreFoundation                -[__NSArrayM dealloc] + 148
6   libqcocoa.dylib               0x10436c000 + 515284
7   CoreFoundation                __RELEASE_OBJECTS_IN_THE_ARRAY__ + 116
8   CoreFoundation                -[__NSArrayM dealloc] + 148
9   libobjc.A.dylib               AutoreleasePoolPage::releaseUntil(objc_object**) + 204
10  libobjc.A.dylib               objc_autoreleasePoolPop + 244
11  CoreFoundation                _CFAutoreleasePoolPop + 32
12  CoreFoundation                __CFRunLoopPerCalloutARPEnd + 48
13  CoreFoundation                __CFRunLoopDoSource0 + 204
14  CoreFoundation                __CFRunLoopDoSources0 + 332
15  CoreFoundation                __CFRunLoopRun + 820
...
27  QtCore                        QCoreApplication::exec() + 216
28  OBS                           0x100b18000 + 1110500

Notes

• This appears related to earlier macOS browser-source crashes on CrBrowserMain (e.g. #4059, #3097) and to reports of a browser-view object being disposed twice.
• I am on the latest stable OBS (32.1.2), so there is no newer version for me to try.
• macOS 26.5.1 is a very recent OS build, which may be part of the trigger.
• The two backtraces come from the same OBS session-run window (crashes at 20:16 and 20:22 local time). The second (idle) crash happened shortly after relaunching from the first.

I have the two full macOS crash reports (.crash / diagnostic text). Happy to attach them or provide the OBS log file if that helps narrow it down.

Start with the obs-browser plugin and the CrBrowserMain frames in both supplied backtraces, then compare the two full macOS crash reports and the OBS log when attached. Determine whether the same browser-source lifecycle failure can be reproduced; done means identifying a confirmed cause and a validated fix or a narrowly documented upstream dependency.