mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 10:15:20 +01:00
[GH-ISSUE #875] Crashing on pulseaudio #264
Labels
No labels
A:Build
A:CI
A:Client
A:Config
A:Core
A:Documentation
A:Documentation
A:IPC
A:Testing
A:UX/UI
blocked
BREAKING CHANGE
duplicate
good first issue
GTK4
help wanted
invalid
M:Battery
M:Battery
M:Bindmode
M:Bluetooth
M:Brightness
M:Cairo
M:Clipboard
M:Clock
M:Clock
M:Custom
M:Focused
M:Keyboard
M:Launcher
M:Menu
M:Music
M:Music
M:Music
M:Network Manager
M:Notifications
M:SysInfo
M:Tray
M:Volume
M:Workspaces
partially resolved
P:Critical
P:High
P:Low
P:Medium
pull-request
T:Bug
T:Bug
T:Core Enhancement
T:Module Enhancement
T:New Module
T:Question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/ironbar#264
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ToxicMushroom on GitHub (Feb 23, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/875
Describe the bug
I don't know why this happens
To Reproduce
:c
Expected behavior
No crashes
System information:
Configuration
Irrelevant I assume
Maybe you need to have the volume or mpd module ?
Added on request*
Config
Additional context
Last log lines before crash:
tagstudiofrequently which removes and creates a new playback stream in pulse.@JakeStanger commented on GitHub (Feb 23, 2025):
This will be related to the volume module. Config for that (esp how many instances) would be useful to know.
Seems like an odd one, and probably horrible to debug. I'll keep this in mind in case I see it, but won't be able to do anything without repro steps.
@ToxicMushroom commented on GitHub (Feb 23, 2025):
I also love software, I added the config for you
@JakeStanger commented on GitHub (Feb 28, 2025):
I'm going to invest some time into logging when I can, so that hopefully you can run with trace logs filtered down to just Pulse and get some more info out if/when it happens again.
@ToxicMushroom commented on GitHub (Mar 1, 2025):
sounds good tyvm
@JakeStanger commented on GitHub (Mar 24, 2025):
Will merge the above PR in a min, which adds some more logging. I've also bothered to learn more about how tracing-subscriber works and turns out it has all the smart filtering stuff built in.
That means you should be able to run with the below to get trace logs for just volume:
Note you'll probably want to set IRONBAR_FILE_LOG too to ensure it gets written to disk.
@JakeStanger commented on GitHub (Mar 24, 2025):
Are you also able to confirm what version of Pulse (or Pipewire-Pulse) you're using please? Just realised I don't have that
@ToxicMushroom commented on GitHub (Mar 24, 2025):
merlijn@statice ~ % pipewire --version
pipewire
Compiled with libpipewire 1.4.1
Linked with libpipewire 1.4.1
@ToxicMushroom commented on GitHub (Mar 24, 2025):
Thanks for the tip, ill add this to my launch script :)
@JakeStanger commented on GitHub (May 20, 2025):
@ToxicMushroom hey, just checking to see if you've seen this crash in the past couple of months?
@ToxicMushroom commented on GitHub (May 20, 2025):
no but it's also been some time since I used that application
@ToxicMushroom commented on GitHub (May 22, 2025):
Imo you can close this, I'll post more info with those logs if I ever get crashes again :)
@JakeStanger commented on GitHub (May 22, 2025):
Cool will do. Shout any time and I can reopen
@quietvoid commented on GitHub (May 24, 2025):
I just started encountering this crash and it seems somewhat random.
Currently installed commit
bd9b3afWill try to get a trace, usually I get a crash when starting playback in the Spotify app.
@ToxicMushroom commented on GitHub (Oct 17, 2025):
@JakeStanger Alright, I'm back to regularly crashing but I'm still on 0.17.0, so idk if the code has changed since ?
@JakeStanger commented on GitHub (Oct 18, 2025):
I did refactor the client code slightly in
0.17.1to fix a crash I found. It was caused by requesting data from Pulse too often, which killed the connection.I have no idea if it's the same one you're encountering, but it might be worth a shot.
@shazow commented on GitHub (Nov 11, 2025):
Not sure if this is the same crash, but happening on
0.17.1:@JakeStanger commented on GitHub (Nov 11, 2025):
Yes that looks like it could be the same issue. Do you have any context as to what could have caused it? Any playing audio, any button clicks, etc?
@shazow commented on GitHub (Nov 11, 2025):
@JakeStanger I haven't noticed, seems quite variable! I don't think there's any music playing, but it seems to happen pretty quickly (like 5-20 minutes?).
Latest crash happened after a minute or two with this error:
Assertion 'q->front' failed at ../src/pulsecore/queue.c:81, function pa_queue_push(). Aborting.My full config is here:
github.com/shazow/nixfiles@dfb6dff521/home/common/ironbar.nix@ToxicMushroom commented on GitHub (Nov 11, 2025):
My audio-crashes stopped again 🙈
@shazow commented on GitHub (Nov 11, 2025):
@ToxicMushroom I'll carry the torch. 😅
@JakeStanger One thing I noticed is that it doesn't crash on my desktop, but does on my laptop. Desktop uses a USB DAC, laptop uses the embedded audio with EasyEffects.
@quietvoid commented on GitHub (Nov 12, 2025):
Just ran into this
It crashed as a YouTube video started in Firefox.
@JakeStanger commented on GitHub (Nov 12, 2025):
That's the first time we've had a cause (even if completely unreplicatable currently), but that looks like it's a different crash 🙃
I'm going to need a lot more information about each crash to attempt to put any of this together, especially considering I am still yet to ever encounter this:
Logs with as much verbosity as you can provide are useful too:
Note you'll probably want to set
IRONBAR_FILE_LOGtoo to ensure it gets written to disk.@quietvoid commented on GitHub (Nov 12, 2025):
For some reason I'm getting issues a lot this morning, perhaps due to upgrade to
easyeffects8.0.There's a lot of sink spam in logs.
Setup:
pipewire-pulse 1:1.4.9-1easyeffects, normally disabled for all output streams.Easy Effects Sinkeasyeffectsdefaulting to "Use default output", making it constantly switch between the two.github.com/JakeStanger/ironbar@25fe56844aTraces: traces.log
Log files:
@shazow commented on GitHub (Nov 20, 2025):
In case this is any help, I've been running ironbar with
IRONBAR_LOG=info,ironbar::clients::volume=trace ironbarfor a while and it has not crashed once since I started doing that. Not sure what this is indicative of. 🫠@JakeStanger commented on GitHub (Nov 20, 2025):
If it turns out to be a race condition I'm throwing a tantrum.
I suspect whatever the cause is, it's not consistent.
easyeffectscertainly seems suspicious.@quietvoid commented on GitHub (Nov 20, 2025):
I had a lot of crashes regardless of whether or not logs were enabled.
Since my last comment I have had the
volumemodule disabled.I could try disabling easyeffects and see how it behaves.
@weightedangelcube commented on GitHub (Apr 12, 2026):
Also experiencing this issue. Crashes commonly occur when one track stops and another starts. Before a crash, the bar rapidly flickers between the EasyEffects and default sink (my ACCENTUM Bluetooth headphones), so I assume #1411 is related if not the same issue.
Playing YouTube Music on Firefox. No crashes nor flickers happen on Waybar.
The crash does not happen with EasyEffects disabled.
@JakeStanger commented on GitHub (Apr 20, 2026):
I've just for the first time ever had the original crash:
No idea what the repro steps are, was doing nothing at the time other than listening to music.
@orestisfl commented on GitHub (Apr 24, 2026):
I managed to reproduce this reliably:
Reproduction script
Crashes with:
My understanding is that two threads concurrently call the thread-unsafe libpulse C API on the same
pa_context:github.com/JakeStanger/ironbar@742fe7f4f1/src/clients/volume/sink.rs (L115)github.com/JakeStanger/ironbar@742fe7f4f1/src/clients/volume/mod.rs (L235)From the libpulse-binding crate:
A safer design for example could be a "single-writer" pattern where:
iteratereturnspubAPI which calls libpulse-binding's to wake the loop:@JakeStanger commented on GitHub (Apr 25, 2026):
Thanks for the repro script and the pointers, that's been a great help.
I wasn't able to go the
wakeuproute exactly. I'm not exactly sure how you're supposed to, becauseMainloopisn't thread-safe. I guess you're supposed to useunsafeto move pointers around and just take the safety into your own hands? Not the loveliest experience.Anyway...I have been able to replace it with the threaded
Mainloop, which can be passed to other threads, and I've implemented the single-writer pattern which has tidied up the code.It's still crashing with the repro script, but under general use it seems more stable - I've been running EasyEffects for a few days & have been able to fairly consistently crash the bar by ie seeking quickly through a YT video, but so far have not been able to with the refactored version.
The current thinking is that the script is probably producing an overwhelming amount of messages that actually ends up overflowing the Pulse events buffer. I'm not sure exactly how we handle that yet, but trying to deduplicate seems key.
For now the refactored version is available in #1469 to test.
EDIT: I've added some basic checks to avoid duplicate calls (just in the area the script runs for now). The bar still crashed, but lasted longer, and we've got a new error:
@orestisfl commented on GitHub (Apr 26, 2026):
Yeah I noticed that. Maybe it's worth upstreaming the change in the library first? I can take a look.
I do have a draft that uses unsafe and makes the script pass so it seems pulseaudio is able to handle it.
@JakeStanger commented on GitHub (Apr 26, 2026):
I'm happy to accept unsafe code so long as it's minimised/sensible/commented. If you've got something working then feel free to supersede my PR!
@JakeStanger commented on GitHub (May 2, 2026):
I've just opened a 2nd PR that uses the sync mainloop as before, with some unsafe code. For me this still crashes, which means either I'm still doing something wrong, or it's environmental (big powerful CPU = easier to overwhelm queue maybe?).
I'd be interested to see if this is the case for other people. Could anybody willing please try both branches with the test script and see if it crashes?
@Funtimes909 commented on GitHub (May 3, 2026):
Tested both crash fix branches (as well as the master branch)
Master branch crashes both times (first run no music, second run with music)
fix/volume-crash does not crash either time
fix/volume-crash2 crashes both times
Script looks like it mentions something about saving logs to a file in a created directory in /tmp? but I couldn't find any files in the directory, so none are included.
The two sinks are two unique bluetooth headphones.
neofetch for system specs
All three binaries were built in release mod (cargo build --release) and all tests were done two times, once while playing music (feishin) and once while not playing anything.
Hope this helps
@JakeStanger commented on GitHub (May 6, 2026):
It's taken until now to realise the repro script uses
target/release/ironbarwhich means...I have to compile in release mode to test 🤦 🤦 🤦After redoing my own testing properly on a couple of devices, I've found the same results. Thanks very much for the thorough test! I'm going to merge the 1st branch & finally close this issue.
Any other issues, let me know & we can re-open or open a new issue.