Crash: pending QTimer::singleShot fires into a destroyed CClientDlg after an audio-device exception

[mcfnord]

MY LLM WROTE:

Describe the bug

If an audio-device error throws while the client is running, the client crashes — not when the error happens, but up to a minute later, while the error dialog is on screen.

This is not #3754. I found it while investigating that issue and checked the connection specifically. #3754 reports BUG IN CLIENT OF LIBMALLOC: not an allocated block at __cxa_finalize_ranges → exit; this is a use-after-scope at timer dispatch. I ran the same chain in stock builds under macOS MallocErrorAbort/MallocGuardEdges and glibc MALLOC_CHECK_=3 and never got an allocator message, which follows once you notice the dangling object is on the stack, so no allocator check can fire. Same code region and same intermittent character, different crash.

CClientDlg is a stack object in main() (main.cpp:1008). A CGenErr thrown from the asynchronous audio-reinit path unwinds main()'s try (main.cpp:978) and destroys it. The handler at main.cpp:1107 then calls QMessageBox::critical (main.cpp:1113), which runs QDialog::exec() — a nested event loop that keeps dispatching timers, and which stays open until the user clicks Quit.

Meanwhile clientdlg.cpp:869 holds a pending timer:

QTimer::singleShot ( 60000, [this]() { lblUpdateCheck->hide(); } );

That is the 2-argument overload. It captures this but registers no context object, so Qt cannot auto-cancel it when CClientDlg is destroyed. When it comes due inside the nested loop it dereferences the destroyed dialog, and the client crashes.

The timer is only armed after connecting to a server that reports a strictly newer, suffix-free version, which is why this is intermittent rather than constant.

It is the only bare call site of its kind in the tree — serverdlg.cpp:924 and :930 already use the 3-argument context-aware form.

To Reproduce

Two things have to overlap: the update-check label must be showing, and an audio-device exception must escape within the timer's 60 seconds.

The second needs no special setup. On JACK, stopping JACK under a running client runs jack_on_shutdown → CSound::shutdownCallback (sound/jack/sound.cpp:463) → EmitReinitRequestSignal ( RS_ONLY_RESTART_AND_INIT ) → CClient::OnSndCrdReinitRequest (client.cpp:849) → Init() → CSound::Init() → throw CGenErr (sound/jack/sound.cpp:338). On CoreAudio the same slot reaches throw CGenErr at sound/coreaudio-mac/sound.cpp:917 and :925 on a buffer-size mismatch. I observed the JACK route happening on its own, with no instrumentation of the throw: the reinit slot entered, both warnings printed, and the dialog destroyed by the unwind.

To measure it rather than wait for luck, I built with two test-only hooks — one driving the real OnCLVersionAndOSReceived slot with version 99.9.9, one throwing from the reinit slot — and shortened the timer. Nothing about the two defects themselves was modified.

Expected behavior

No crash. A timer whose callback touches a widget should not outlive that widget.

Screenshots

Not applicable.

Operating system

Reproduced on both, built from source:

• Ubuntu Linux, Qt 5.15.13, offscreen QPA
• macOS 12.7.6, x86_64, Qt 5.15.2

Version of Jamulus

3.12.2dev. All line numbers above are against current main (9d1eca4e), where both defects are unchanged. The singleShot line has been as it is since e9865ff2 (2026-05-14).

Additional context

28/28 crashes under ASan (Linux 20/20, macOS 8/8), with identical stacks on both platforms:

<lambda>  clientdlg.cpp:869
QSingleShotTimer::timerEvent
QTimerInfoList::activateTimers
QEventLoop::exec
QDialog::exec              <- the QMessageBox

ASan classifies it stack-use-after-scope, READ of size 8 — stack rather than heap, which follows from the dialog living in main()'s frame. Stock builds without ASan crash just as reliably: 15/15 SIGSEGV on Linux, 8/8 EXC_BAD_ACCESS on macOS, with QWidget::hide() on top.

This does not fire on the normal quit path, which is presumably why it has gone unnoticed. I measured that rather than assuming it: a 2 ms heartbeat timer outliving the dialog shows Qt stops dispatching timers within ±2 ms of close() being called, with roughly 110 further ticks due and none delivered, 3/3 on each platform. The error path is what makes the bug reachable, because a modal dialog inside an exception handler is a fully pumping event loop running after stack objects have been unwound.

Two independent one-line fixes:

// clientdlg.cpp:869 - Qt auto-cancels when the context object is destroyed
QTimer::singleShot ( 60000, this, [this]() { lblUpdateCheck->hide(); } );

// client.cpp:856 / 891 - releases the mutex even if an exception unwinds
QMutexLocker locker ( &MutexDriverReinit );

The first stops this crash. The second stops the exception escaping in the first place, and fixes a second problem on that path: the throw skips MutexDriverReinit.unlock() at client.cpp:891, so the mutex is left locked permanently. Every trial prints both Qt has caught an exception thrown from an event handler and QMutex: destroying locked mutex. There are three catch ( CGenErr ) sites — main.cpp:1107, clientdlg.cpp:1254, recorder/jamrecorder.cpp:432 — and none of them covers this asynchronous path.

[softins]

This makes sense, and so do the proposed fixes. I'll raise a PR for them, unless that's already being done.

[mcfnord]

This makes sense, and so do the proposed fixes. I'll raise a PR for them, unless that's already being done.

I'll ask a robot to draft something.

[softins]

I tried both main and my branch with those two fixes, on my Pi running Raspbian 12 with Jack audio. In both cases, stopping Jack in QJackCtl threw a CGenErr exception, but it was not caught by the catch in main.cpp. Instead, it caused the app to be aborted. I am not clear enough on the exception throw path from within the app. Maybe it was thrown in a different thread? I have seen something about sound handling being in a separate thread. If so, I imagine the exception will not reach the caller of pApp->exec(). I'd be interested in Claude's analysis of this.

[mcfnord]

MY LLM WROTE:

I logged thread IDs at each step of the real path (stop JACK under a running client), Qt 5.15.13 / x86_64:

• shutdownCallback runs on a JACK thread (tid A).
• It does emit ReinitRequest(...). The Sound → CClient::OnSndCrdReinitRequest connection is a default (Auto) one, and since the emit is cross-thread, Qt delivers it as a queued meta-call.
• OnSndCrdReinitRequest therefore runs on the main thread (tid B, the thread that called pApp->exec()), and that is where Init() throws CGenErr.

So the exception is not thrown in the sound thread. The queued connection marshals it to the main thread and it is thrown there, from inside event-loop dispatch. That is why it can reach the catch in main.cpp at all — but it gets there by propagating through Qt's event loop, which Qt does not support. Every run prints:

Qt has caught an exception thrown from an event handler. … in Qt 5 you must at least reimplement QCoreApplication::notify() and catch all exceptions there.

Whether that unsupported propagation ends in your catch or in std::terminate is decided by the platform's event dispatcher, not by the code. On my x86 build it is caught (the app then opens the error dialog — which is what makes the singleShot UAF in this issue reachable). On your Pi it aborts. Both are valid outcomes of the same unsupported operation, which is why we saw different results.

Consequence for the fixes: the two one-liners are still correct, but they do not cover what you hit. The singleShot change removes the specific use-after-scope; the QMutexLocker releases the reinit mutex on unwind. Neither stops the exception from crossing the event loop, so on a dispatcher that terminates, the app still aborts.

The portable fix is the one that Qt message asks for: don't let the exception leave the slot. Catching CGenErr inside OnSndCrdReinitRequest and surfacing the text through the normal GUI channel removes all three symptoms at once. Measured on the same rig with that catch added: no "Qt has caught an exception", no QMutex: destroying locked mutex, and the client keeps running — against the warning plus leaked mutex on every unpatched run.

One design point for you before I add it to the PR: today a fatal audio error shows a critical dialog and quits. A slot-level catch can either keep that behaviour (post the error to the main thread, then quit cleanly) or recover and continue. Which do you want?

I also ran the same real jack-stop rig on ARM to try to reproduce the terminate half directly: Raspberry Pi 4 aarch64 (Qt 5.15.15), and — to match your build as closely as I could without your exact Raspbian image — a native (no QEMU) Debian 12 "bookworm" arm64 chroot on that same Pi giving Qt 5.15.8, both under offscreen and under xcb+Xvfb. All four caught the exception and survived, same as x86. So arch, Qt 5.15 point release, and QPA backend don't flip the outcome on their own — it's most likely something specific to your Raspberry Pi OS Qt build or real (non-virtualized) JACK hardware timing that I can't reach from here.

One thing that would pin it down cheaply: right before your abort, does the console print "Qt has caught an exception thrown from an event handler…"? If yes, you're hitting the same rethrow-then-terminate path I measured, just landing on the terminate side of it. If that line is absent, something different is happening on your build and I'd want to look closer before assuming the same fix covers it.