Bug: OBS crash (SIGSEGV in obs-websocket thread, strlen(NULL)) on scene switch while streaming starts — macOS ARM64

[Vany]

Description

OBS 32.1.0 crashes with EXC_BAD_ACCESS (SIGSEGV) in a background obs-websocket worker thread shortly after switching scenes while streaming is starting. The crash is strlen(NULL) inside obs-websocket, not in OBS core.

Environment

• OBS Version: 32.1.0 (mac)
• obs-websocket Version: 5.7.2 (RPC Version: 1)
• OS: macOS 26.3.1 (Build 25D2128)
• Hardware: Apple M4 Max, Mac16,5 (ARM64, native — Rosetta: false)
• Qt Version: 6.8.3

Steps to Reproduce

1. Launch OBS with obs-websocket enabled (port 4455)
2. Start streaming
3. Switch scenes (e.g. from Glasses → Game) shortly after streaming begins

Crash Report Summary

Exception: EXC_BAD_ACCESS (SIGSEGV) — KERN_INVALID_ADDRESS at 0x0000000000000000

Crashing thread: Thread (pooled) — a background worker inside obs-websocket

Crashing stack (from macOS .ips crash report):

Thread "Thread (pooled)" — triggered: true
  _platform_strlen +4          [libsystem_platform]  ← crash: strlen(NULL)
  obs-websocket +71772
  obs-websocket +460248
  obs-websocket +312824
  obs-websocket +819396
  obs-websocket +785884
  QtCore +2213584
  QtCore +2182424
  _pthread_start +136
  thread_start +8

Thread state at crash:

• pc = _platform_strlen + 4
• far = 0x0 (the null address being read)
• esr = 0x5720_0006 — "Data Abort, byte read, Translation fault" (null dereference)

The crash is reproducible as a race condition at stream-start time: it happened twice in rapid succession. After restarting OBS a third time it ran stably for 7+ hours with many scene switches.

Hypothesis

obs-websocket serializes a CurrentProgramSceneChanged event in a pooled thread and calls strlen() on a scene/source name field that is nullptr at that moment — likely a race with the streaming output initialization or a scene that has a null display name.

Additional Context

A WebSocket client (browser app) was connected to obs-websocket from [::1]:55117 at the time of the crash. The client only subscribed to StreamStateChanged and RecordStateChanged — not CurrentProgramSceneChanged. The crash still occurred, confirming it is server-side in obs-websocket's event emission code.

OBS log confirms the sequence:

20:49:24.883: [obs-websocket] New WebSocket client connected from [::1]:55117
20:49:26.648: [rtmp stream] Connection successful (streaming started)
20:50:07.054: User switched to scene 'Glasses'
20:50:25.912: User switched to scene 'Game'
<crash at 20:50:26>

Full .ips crash report available on request.

[Vany]

Update — identified the trigger path:

The connected client was sending an Identify message without eventSubscriptions, which defaults to all events. This means obs-websocket was broadcasting CurrentProgramSceneChanged to our client on every scene switch, going through the serialization code path that contains the null pointer.

After setting eventSubscriptions: 64 (Outputs only — we only need StreamStateChanged and RecordStateChanged), the crash no longer occurs on scene switches.

So the null string is hit in the CurrentProgramSceneChanged event serialization path, likely a race with scene/source initialization during stream start. The bug exists server-side in obs-websocket, but the workaround is to not subscribe to scene events if you don't need them.