Renderer init failure crashes in the FatalError path (SIGSEGV, null soundSystem) instead of reporting the error

[rebelancap]

Summary

When renderer device initialisation fails, common->FatalError is reached but the process segfaults on a null soundSystem before the error is shown. A recoverable, clearly-diagnosable configuration problem therefore presents to the user as an unexplained SIGSEGV.

Environment

• macOS 27.0, Apple M4 Pro, Xcode 26.6
• openQ4 227ee810 (main), release build, platform_backend=sdl3

Reproduce

Any Vulkan init failure will do. The easiest is to run .install/ without MoltenVK staged where the SDL3 backend probes for it (that packaging mismatch is #95):

cd .install && ./openQ4-client_arm64 +set r_renderApi vulkan

Observed:

openQ4: fatal signal SIGSEGV (11), exiting without unsafe engine shutdown
openQ4: last renderer startup phase: idle
openQ4: last game module phase: idle

Under lldb:

stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: idSoundSystem::StopAllSounds(int) + 20
->  0x1002d7f7c <+20>: ldr    x8, [x0]     ; x0 == 0
    0x1002d7f80 <+24>: ldr    x1, [x8, #0x18]
    0x1002d7f88 <+32>: br     x1

That is a virtual dispatch through a null object — soundSystem is null at the point the fatal-error path calls into it. (lldb cannot unwind past frame #0 because the thunk tail-calls, so the caller frame is already gone.)

The actual, useful message is only visible with +set logFile 2, in <fs_savepath>/baseoq4/qconsole.log:

----- VK_InitRenderDevice -----
WARNING: Vulkan: window creation failed
FATAL: Vulkan renderer device initialization failed

Note on diagnosis difficulty

Without logFile 2 this is genuinely misleading: stdout is block-buffered, so several KB of output is lost on the crash and the last line to reach the terminal is from a much earlier part of startup (machine-spec detection, mid-Printf):

	Video memory: 37.44 GB on an opopenQ4: fatal signal SIGSEGV (11), ...

That points investigators at the wrong subsystem entirely. Flushing (or fflush on the fatal path) before the handler exits would help a lot on its own.

Suggested fix

Null-guard the sound teardown on the fatal-error/shutdown path, as is already done elsewhere in the codebase — e.g. Session.cpp:4594:

if ( soundSystem ) {
    soundSystem->StopAllSounds( SOUNDWORLD_GAME );
}

More generally, the fatal-error path can be entered before or during subsystem init, so it should tolerate any subsystem being absent rather than assuming a fully-initialised engine.

Why this matters

A renderer that fails to initialise is exactly the situation where the user most needs to read the error — wrong driver, missing loader, unsupported device. Crashing first turns a one-line fix into a debugging session, and it hides genuinely actionable messages like the window creation failed above.

[themuffinator]

Thanks for the detailed report — the bug is real and now fixed in 2b99802, but the diagnosis is one indirection off, and the suggested fix was already in the tree at the exact line that crashes.

soundSystem isn't null — the sound world is

Session.cpp:4594, which you cited as the model guard from elsewhere, is the guard around the crashing call:

if ( soundSystem ) {
    soundSystem->StopAllSounds( SOUNDWORLD_GAME );   // <- crashes here
}

It predates 227ee810, and it's the only soundSystem->StopAllSounds call site in the tree. If soundSystem were null it would have skipped the call. It can't be: snd_system.cpp:60 binds it statically (idSoundSystem* soundSystem = &soundSystemLocal;), so it's never null in the engine binary.

The null is one level down. idSoundSystem::StopAllSounds(int) is sound.h:461:

virtual void StopAllSounds(int worldId) {
    GetSoundWorldFromId(worldId)->StopAllSounds();
}

GetSoundWorldFromId(SOUNDWORLD_GAME) returns session->sw (snd_system.cpp:910), which idSessionLocal::Init allocates — and InitGame runs session->Init() after InitRenderSystem(). So a renderer that fails to come up tears down with soundSystem live and session->sw still null.

Your disassembly agrees, on a second read: +20 is the second vtable load in that function, on the value GetSoundWorldFromId just returned.

+8 : ldr x8, [x0]        ; soundSystem->vtable    (this: fine)
+16: blr x8              ; GetSoundWorldFromId() -> x0 = session->sw = NULL
+20: ldr x8, [x0]        ; <- crash
+24: ldr x1, [x8, #0x18] ; StopAllSounds() slot
+32: br  x1              ; tail call -- hence the missing caller frame

The "null soundSystem" reading is a fair guess, incidentally: the renderer module really does carry its own soundSystem that starts NULL (RendererGLModule.cpp:68). That copy just isn't on this path.

Not macOS-specific, not Vulkan-specific

The GL ladder calls common->FatalError( "Unable to initialize OpenGL" ) from the same InitOpenGL() at the same point in boot (RenderSystem_init.cpp:1687). Every platform, both backends: a renderer that fails to initialise segfaulted instead of reporting.

What changed in 2b99802

• All eight idSoundSystem helpers that forward through GetSoundWorldFromId now null-check the world, matching the check idSoundSystemLocal::FreeSoundEmitter already made on the same accessor. AllocSoundEmitter returns the reserved invalid handle 0, which EmitterForIndex and FreeSoundEmitter both already treat as "none".
• Your note about lost stdout was right and worth acting on: Sys_Printf writes through stdio, and the fatal signal handler ends in _exit(), which discards every buffered stream. The error paths now flush before running teardown that can fault.
• Sys_SetFatalError already parks the message before the crashing Shutdown() — the handler was simply ignoring it. It now writes the parked message to stderr and to the fatal breadcrumb file, so a fault during teardown still names the cause instead of leaving a bare SIGSEGV.

I also walked the rest of the teardown for a half-built engine: SetGUI(NULL,NULL) early-returns, arenaCampaign.Shutdown() early-returns on a null state, uiManager->Shutdown() is empty-list safe, bse->Shutdown() tolerates never having been Inited, renderSystem->Shutdown() guards on glConfig.isInitialized, and everything else on the path is either guarded or was initialised before the renderer. So the sound-world guard should be sufficient rather than just moving the crash — though I'd appreciate a confirmation from your side, since I can't run the Vulkan path on Apple hardware.

tools/tests/fatal_error_startup_safety.py pins all of this, including the soundSystem->Init() / InitRenderSystem() / session->Init() ordering that makes the null reachable.

Still open

last renderer startup phase: idle was accurate but useless here: every R_RecordRendererStartupPhase call site is on the GL bring-up ladder, and the Vulkan seam in idRenderSystemLocal::InitOpenGL records nothing. That's a separate gap and I've left it out of this change rather than half-fix it — worth its own issue.

None of this touches #95; it just means a MoltenVK staging mismatch now reports Vulkan: window creation failed / Vulkan renderer device initialization failed on the terminal instead of segfaulting first.