souvlaki panics in debug builds on macos but not in release builds

[Porkepix]

Environment & Versions

• System: macos
• Termusic version: master with cargo
• Rust version: 1.94.1

Logs:

Logs

[2026-04-04T17:48:13.767+02:00 INFO termusicplayback::backends::rusty::decoder]: Found supported container with trackid 0 and codectype 0x2000
[2026-04-04T17:48:13.880+02:00 INFO termusicplayback]: Not restoring Last position as it is not enabled for Music
[2026-04-04T17:48:13.880+02:00 WARN discord_rich_presence::ipc_unix]: find_pipe: could not find pipe
[2026-04-04T17:48:13.885+02:00 ERROR termusic_server::logger]: Panic occured:
panicked at /Users/[me]/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/souvlaki-0.8.3/src/platform/macos/mod.rs:324:24:
null pointer dereference occurred
disabled backtrace
~

Description of the Problem

Everything related to play (or so it seems) is broken. This happens only on debug builds (here cargo build --locked). Verified as not happening on Linux (and the file where the panic occurs is clearly about macos). I don't know nor can I test for Windows.

Issue seems related to a crate, so it might require an upstream report there. It's still weird it affect only debug builds.

Additional observations:

• I don't know if it's possible to have logs at a more predictable location on mac, they currently are at a location with unpredictable path so I had to search after them:

❯ fd termusic-server.log /
/private/var/folders/vf/ptf858lx6mv_3hdbs1z6s85w0000gn/T/termusic-server.log
/System/Volumes/Data/private/var/folders/vf/ptf858lx6mv_3hdbs1z6s85w0000gn/T/termusic-server.log

(README mentioned with an interrogation /tmp for mac, so it's actually incorrect)

• Should the Discord part (line 3) appears as a warning when we don't use such features?
• First line was making me curious with codectype 0x2000, trackid and so on.

EDIT: Out of topic, but I was surprised that, when the laptop was under heavy load (still compiling one termusic), launching termusic had music play start instantly but several seconds of delay in build and showing the UI. It the (T)UI that heavy and demanding in resources that there's such a difference under heavy load between the music startup timing, and when the TUI is drawn?

[hasezoey]

re #691?

I don't know if it's possible to have logs at a more predictable location on mac, they currently are at a location with unpredictable path so I had to search after them:

By the default they are in the system's TMP directory. This can be overwritten with the --log-file option (iirc, this only applies to one binary, not to the server if the tui starts it). Alternatively a environment variable TM(S)_LOGFILE is available (with the S for the server).

(README mentioned with an interrogation /tmp for mac, so it's actually incorrect)

As i (and likely tramhao) dont have a mac, we couldnt confirm that, hence why it is marked (?).

EDIT: Out of topic, but I was surprised that, when the laptop was under heavy load (still compiling one termusic), launching termusic had music play start instantly but several seconds of delay in build and showing the UI. It the (T)UI that heavy and demanding in resources that there's such a difference under heavy load between the music startup timing, and when the TUI is drawn?

I dont quite know what it is in your case, but if you had a relatively big playlist (more than ~10 songs actually), it needs to load the playlist fully before the tui becomes interactive. (re #493)

Should the Discord part (line 3) appears as a warning when we don't use such features?

Currently discord integration is non-optional in terms of compiling, but can be disabled in the config.

First line was making me curious with codectype 0x2000, trackid and so on.

Just information about the track that was loaded. (where trackid 0 is literally audio track 0 in your file; it is possible to play audio on a video, where it might be trackid 1; and codectype 0x2000 is just FLAC)

Issue seems related to a crate, so it might require an upstream report there. It's still weird it affect only debug builds.

[2026-04-04T17:48:13.885+02:00 ERROR termusic_server::logger]: Panic occured:
panicked at /Users/[me]/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/souvlaki-0.8.3/src/platform/macos/mod.rs:324:24:
null pointer dereference occurred
disabled backtrace

Yeah this is a upstream issue, at least the lack of error details is.
This might be something we cause, but without further detail or a device to try on, i dont think i will be able to narrow it down.

If you disable config option use_mediacontrols in server.toml, does the panic still occur? (this will disable media controls though)

As for why it works in release mode, i have no clue, the code there does not seem to use and cfg(debug) or something, but maybe the macro does some debug_asserts.

Btw, this also likely explains why nothing happens when you press any button: the panic exited the backend audio thread. (for those cases more handling is still necessary to fully exit or try to restart)

[Porkepix]

re #691?

I don't know if it's possible to have logs at a more predictable location on mac, they currently are at a location with unpredictable path so I had to search after them:

By the default they are in the system's TMP directory. This can be overwritten with the --log-file option (iirc, this only applies to one binary, not to the server if the tui starts it). Alternatively a environment variable TM(S)_LOGFILE is available (with the S for the server).

Well, I didn't changed any default, and as you can see above it stored them elsewhere…

(README mentioned with an interrogation /tmp for mac, so it's actually incorrect)

As i (and likely tramhao) dont have a mac, we couldnt confirm that, hence why it is marked (?).

EDIT: Out of topic, but I was surprised that, when the laptop was under heavy load (still compiling one termusic), launching termusic had music play start instantly but several seconds of delay in build and showing the UI. It the (T)UI that heavy and demanding in resources that there's such a difference under heavy load between the music startup timing, and when the TUI is drawn?

I dont quite know what it is in your case, but if you had a relatively big playlist (more than ~10 songs actually), it needs to load the playlist fully before the tui becomes interactive. (re #493)

This might be the cause then, yes, as the list add some elements. I'm still surprised by the time it needed for a TUI. But I guess the compilation done at the same time take its toll on resources.

Issue seems related to a crate, so it might require an upstream report there. It's still weird it affect only debug builds.

[2026-04-04T17:48:13.885+02:00 ERROR termusic_server::logger]: Panic occured:
panicked at /Users/[me]/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/souvlaki-0.8.3/src/platform/macos/mod.rs:324:24:
null pointer dereference occurred
disabled backtrace

Yeah this is a upstream issue, at least the lack of error details is. This might be something we cause, but without further detail or a device to try on, i dont think i will be able to narrow it down.

If you disable config option use_mediacontrols in server.toml, does the panic still occur? (this will disable media controls though)

As for why it works in release mode, i have no clue, the code there does not seem to use and cfg(debug) or something, but maybe the macro does some debug_asserts.

Btw, this also likely explains why nothing happens when you press any button: the panic exited the backend audio thread. (for those cases more handling is still necessary to fully exit or try to restart)

Yes, disabling it fixes the panic!

While testing this though, I also noticed discrepancies on quitting termusic: sometimes quitting with q let the server plays music in the background, sometimes it doesn't. As I think you asked about this in the other PR.
EDIT: And I don't know what's the intended behavior here.

[hasezoey]

By the default they are in the system's TMP directory. This can be overwritten with the --log-file option (iirc, this only applies to one binary, not to the server if the tui starts it). Alternatively a environment variable TM(S)_LOGFILE is available (with the S for the server).

Well, I didn't changed any default, and as you can see above it stored them elsewhere…

I dont actually know where the TMP is in macos, so for the README i just put my best UNIX guess.
I just gave it another look, macos seemingly has its (user?) tmp in /private/var. The exact path can be listed with echo $TMPDIR. source

I dont quite know what it is in your case, but if you had a relatively big playlist (more than ~10 songs actually), it needs to load the playlist fully before the tui becomes interactive. (re #493)

This might be the cause then, yes, as the list add some elements. I'm still surprised by the time it needed for a TUI. But I guess the compilation done at the same time take its toll on resources.

Yeah, for me the bottleneck is slow storage, but i guess CPU time / RAM latency could also be a problem as on add (or open) it opens each track to get the metadata for the list.

Yeah this is a upstream issue, at least the lack of error details is. This might be something we cause, but without further detail or a device to try on, i dont think i will be able to narrow it down.
If you disable config option use_mediacontrols in server.toml, does the panic still occur? (this will disable media controls though)

Yes, disabling it fixes the panic!

Great to hear, though without a device to test myself, i cannot fix it and have to wait until it is fixed upstream (at least until a better error is provided).
So we will have to rely on this workaround for now.

While testing this though, I also noticed discrepancies on quitting termusic: sometimes quitting with q let the server plays music in the background, sometimes it doesn't. As I think you asked about this in the other PR.

Yes that is what i meant for testing.
Just to confirm, you have quit_server_on_exit enabled in tui.toml?
It might be because there is another client connected(?).
In any case, could you provide logs there from the server if it happens again? (though i would need the logs for when the server was started with RUST_LOG=info,termusic_server=trace,termusic=trace (which will be populated to the server if started by the tui))

[Porkepix]

I dont actually know where the TMP is in macos, so for the README i just put my best UNIX guess. I just gave it another look, macos seemingly has its (user?) tmp in /private/var. The exact path can be listed with echo $TMPDIR. source

Yes, but here it rather seems to be located in /var. It seems to have the same kind of mechanisms as /tmp. The path to my log files here doesn't mention /tmp anywhere.

Yeah, for me the bottleneck is slow storage, but i guess CPU time / RAM latency could also be a problem as on add (or open) it opens each track to get the metadata for the list.

Gen4 m.2/PCIe SSD here so I doubt disk I/O was the bottleneck!

Yes that is what i meant for testing. Just to confirm, you have quit_server_on_exit enabled in tui.toml? It might be because there is another client connected(?). In any case, could you provide logs there from the server if it happens again? (though i would need the logs for when the server was started with RUST_LOG=info,termusic_server=trace,termusic=trace (which will be populated to the server if started by the tui))

Yup I can confirm.

[Porkepix]

Yeah, for me the bottleneck is slow storage, but i guess CPU time / RAM latency could also be a problem as on add (or open) it opens each track to get the metadata for the list.

To add to this, is it possible that debug build would be significantly slower on the matter?

Comparing the debug build to the release one, I think I can say it's roughly 3 to 4 times slower to display the UI (test without significant load).

[hasezoey]

I dont actually know where the TMP is in macos, so for the README i just put my best UNIX guess. I just gave it another look, macos seemingly has its (user?) tmp in /private/var. The exact path can be listed with echo $TMPDIR. source

Yes, but here it rather seems to be located in /var. It seems to have the same kind of mechanisms as /tmp. The path to my log files here doesn't mention /tmp anywhere.

In the referenced stackoverflow, it seems like /tmp is a symlink to the /private/somewhere path, and some more recent one has moved it around again, also symlinking it.
Try:

echo $TMPDIR
ls -al /tmp
ls -al /private

Yeah, for me the bottleneck is slow storage, but i guess CPU time / RAM latency could also be a problem as on add (or open) it opens each track to get the metadata for the list.

To add to this, is it possible that debug build would be significantly slower on the matter?

Comparing the debug build to the release one, I think I can say it's roughly 3 to 4 times slower to display the UI (test without significant load).

Debug builds are definitely slower than release as they contain practically zero optimizations applied, but for this specific case, i have now clue why it would be that slow, unless you use like 1k songs or more in the playlist. Though my measurements / experience are all from linux x86 on rather modern systems, so it could be possible that there is something very unoptimized in debug for arm.

[Porkepix]

In the referenced stackoverflow, it seems like /tmp is a symlink to the /private/somewhere path, and some more recent one has moved it around again, also symlinking it. Try:

echo $TMPDIR
ls -al /tmp
ls -al /private

/tmp is a symlink and lead to /private/tmp.
Here logs are into private/var/…; /var is a symlink leading there.
So for some curious reasons those logs are stored under /var rather than /tmp on mac.