You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since about the first rawaudio builds, i noticed the Jamulus client sometimes crashing when exiting the app. This has been reported along the rawaudio build discussions by several users though no clear link to the patch could be found, so might as well be unrelated.
Also, latest 4.0 beta1 sometimes crashes on my native M1 build, stacktrace by Apple crash reporter is not super helpful but at least dumps some lines about malloc / mutex calls.
What is interesting is, that @ann0see by accident left a Copilot code analysis report of the iOS build in 00e8668#diff-78ed0fa926a94e116646dc6705a0e993e2ab613c66e3fc2d06376096cb6d6e79 which points to the same direction. Nowadays, macOS and iOS/iPadOS on Apple Silicon share a lot of framework and libs, if not even system libs and kernel (not sure). So there might be a relationship to the Copilot report.
To Reproduce
Very hard to reproduce. Install latest 4.0 beta1 on Apple Silicon (M1 Pro for me). Run, exit, run, exit, run, exit... sometimes after a few attempts Apple reports an app crash with dump.
EXC_BREAKPOINT / SIGTRAP
libsystem_malloc.dylib: BUG IN CLIENT OF LIBMALLOC: not an allocated block
AppleUnifiedLogger::messageHandler(...)
__cxa_finalize_ranges → exit
(?) is this the crash? it might be a qt bug. We cannot upgrade Qt at the moment unfortunately due to #3646 (comment)
We tried to reproduce this under AddressSanitizer on Linux and could not trigger it in ~6,000 client connect→exit cycles (ASan close and quit paths, plus a stock -O2 build at real timing). ASan makes a double-free or use-after-free deterministic, so a common shared-code lifetime bug would have fired almost immediately. It did not — and no Qt cross-thread teardown warning (Timers cannot be stopped from another thread, QSocketNotifier: ...) appeared on stderr in any run.
Since the crash frames are macOS-only (AppleUnifiedLogger::messageHandler, libmalloc "not an allocated block" during __cxa_finalize), this looks platform-specific rather than a shared-code defect — consistent with the "might be Qt" concern on #3646.
The fastest way to pin it would be data from someone who can reproduce on macOS: a symbolized crash report, or a run with MallocStackLogging=1 MallocScribble=1, or best a macOS -fsanitize=address build (which would name the allocation, the free, and the offending access). Happy to share the exact ASan build/run recipe.
I tried reproducing this under AddressSanitizer, on both Linux and macOS, and could not — sharing the negative result in case it helps narrow things down.
Setup: added two env-gated test hooks to a local build (JAMULUS_AUTOCLOSE_MS for the normal close-button teardown, JAMULUS_DIRECTQUIT_MS for a direct quit that skips closeEvent, similar to Cmd+Q/Dock Quit), then stress-looped each path with randomized timing.
Linux: ~6000 iterations across ASan, TSan, and a stock build. All clean.
macOS: 200 iterations of each quit path (400 total), built with clang ASan on a GitHub Actions macos-26 (Apple Silicon) runner, Xcode 26.5, Qt 6.10.2 — chosen to match @foobarth's platform (macOS 26.5.1, Apple Silicon M1 Pro) as closely as CI allows. All clean: no ASan reports, no crash logs.
Caveat: GitHub's macOS runners are VMs (Apple Virtualization Framework on Azure-hosted hardware), not bare metal. If this is a teardown-thread race, a hypervisor scheduling layer could be masking or shifting it the same way ASan's own instrumentation might on Linux — so this result narrows things down but doesn't rule the bug out.
Happy to share the workflow/build setup if it's useful for anyone else trying to reproduce.
Activity
dingodoppelt commentedon Jun 27, 2026
I experience very rare crashes on exiting the app on Linux as well. The crash dumps look similar.
ann0see commentedon Jul 10, 2026
EXC_BREAKPOINT / SIGTRAP
libsystem_malloc.dylib: BUG IN CLIENT OF LIBMALLOC: not an allocated block
AppleUnifiedLogger::messageHandler(...)
__cxa_finalize_ranges → exit
(?) is this the crash? it might be a qt bug. We cannot upgrade Qt at the moment unfortunately due to #3646 (comment)
mcfnord commentedon Jul 23, 2026
Note
📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.
We tried to reproduce this under AddressSanitizer on Linux and could not trigger it in ~6,000 client connect→exit cycles (ASan close and quit paths, plus a stock
-O2build at real timing). ASan makes a double-free or use-after-free deterministic, so a common shared-code lifetime bug would have fired almost immediately. It did not — and no Qt cross-thread teardown warning (Timers cannot be stopped from another thread,QSocketNotifier: ...) appeared on stderr in any run.Since the crash frames are macOS-only (
AppleUnifiedLogger::messageHandler,libmalloc "not an allocated block"during__cxa_finalize), this looks platform-specific rather than a shared-code defect — consistent with the "might be Qt" concern on #3646.The fastest way to pin it would be data from someone who can reproduce on macOS: a symbolized crash report, or a run with
MallocStackLogging=1 MallocScribble=1, or best a macOS-fsanitize=addressbuild (which would name the allocation, the free, and the offending access). Happy to share the exact ASan build/run recipe.ann0see commentedon Jul 23, 2026
You could try to use a macOS CI runner in GitHub actions.
Switch jamulussoftware#3754 repro workflow to push trigger, hardcode …
mcfnord commentedon Jul 23, 2026
Note
📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.
I tried reproducing this under AddressSanitizer, on both Linux and macOS, and could not — sharing the negative result in case it helps narrow things down.
Setup: added two env-gated test hooks to a local build (
JAMULUS_AUTOCLOSE_MSfor the normal close-button teardown,JAMULUS_DIRECTQUIT_MSfor a direct quit that skipscloseEvent, similar to Cmd+Q/Dock Quit), then stress-looped each path with randomized timing.macos-26(Apple Silicon) runner, Xcode 26.5, Qt 6.10.2 — chosen to match @foobarth's platform (macOS 26.5.1, Apple Silicon M1 Pro) as closely as CI allows. All clean: no ASan reports, no crash logs.Caveat: GitHub's macOS runners are VMs (Apple Virtualization Framework on Azure-hosted hardware), not bare metal. If this is a teardown-thread race, a hypervisor scheduling layer could be masking or shifting it the same way ASan's own instrumentation might on Linux — so this result narrows things down but doesn't rule the bug out.
Happy to share the workflow/build setup if it's useful for anyone else trying to reproduce.
ann0see commentedon Jul 24, 2026
Maybe try to find any crash logs. But it could well be different in a VM. I believe a qt upgrade will fix it.
foobarth commentedon Jul 24, 2026
Can you provide a debug build with all the symbols? Happy to install and report back as the crash is reproducible every few launches on my box.