Environment
- wf-shell: r464.f926b19 (AUR wf-shell-git)
- WirePlumber: 0.5.14
- PipeWire: 1.6.3
- OS: CachyOS (Arch-based), kernel 7.0.0-1-cachyos
- DE: Wayfire (Wayland)
- GTK: libgtkmm-4.0
Description
wf-panel crashes intermittently (every 15–30 minutes) with SIGSEGV when the wp-mixer widget is active. The crash is triggered by a WirePlumber mixer event (volume change,
mute, or audio device state change) firing a GObject signal that calls into Gtk::ToggleButton::set_active() on a destroyed or dangling widget.
Crash signal & address
Signal: SIGSEGV at address 0xffffffffffffffe8 (= -0x18, classic null/freed vtable dereference)
Stack trace (thread 1 — crashing thread)
#0 Gtk::ToggleButton::set_active(bool) [libgtkmm-4.0.so.0]
#1 [wf-panel + 0xc3257]
#2 g_cclosure_marshal_VOID__UINTv [libgobject-2.0.so.0]
#3 g_signal_emit [libgobject-2.0.so.0]
#4–#5 (WirePlumber mixer-api signal emission) [libwireplumber-module-mixer-api.so]
#6–#9 libwireplumber-0.5.so.0 / libpipewire-module-protocol-native.so
#10+ g_main_context_iteration → g_application_run → main
Secondary symptom
After the crash, restarting wf-panel directly causes an immediate re-crash. The panel only survives restart after a full Wayfire session logout/login. This suggests WirePlumber
fires mixer signals synchronously on client reconnect, hitting the same unguarded callback before the widget lifecycle is ready.
Workaround
Running systemctl --user restart wireplumber && sleep 2 && wf-panel & allows the panel to restart without immediately re-crashing.
Suspected root cause
The wp-mixer widget's WirePlumber signal handler calls Gtk::ToggleButton::set_active() without verifying the widget is still alive. This is either a use-after-free (widget
destroyed, callback not disconnected) or a signal firing before widget construction completes.
Config
widgets_right = command-output tray notifications wp-mixer battery clock
Environment
Description
wf-panel crashes intermittently (every 15–30 minutes) with SIGSEGV when the
wp-mixerwidget is active. The crash is triggered by a WirePlumber mixer event (volume change,mute, or audio device state change) firing a GObject signal that calls into
Gtk::ToggleButton::set_active()on a destroyed or dangling widget.Crash signal & address
Signal: SIGSEGV at address 0xffffffffffffffe8 (= -0x18, classic null/freed vtable dereference)
Stack trace (thread 1 — crashing thread)
#0 Gtk::ToggleButton::set_active(bool) [libgtkmm-4.0.so.0]
#1 [wf-panel + 0xc3257]
#2 g_cclosure_marshal_VOID__UINTv [libgobject-2.0.so.0]
#3 g_signal_emit [libgobject-2.0.so.0]
#4–#5 (WirePlumber mixer-api signal emission) [libwireplumber-module-mixer-api.so]
#6–#9 libwireplumber-0.5.so.0 / libpipewire-module-protocol-native.so
#10+ g_main_context_iteration → g_application_run → main
Secondary symptom
After the crash, restarting wf-panel directly causes an immediate re-crash. The panel only survives restart after a full Wayfire session logout/login. This suggests WirePlumber
fires mixer signals synchronously on client reconnect, hitting the same unguarded callback before the widget lifecycle is ready.
Workaround
Running
systemctl --user restart wireplumber && sleep 2 && wf-panel &allows the panel to restart without immediately re-crashing.Suspected root cause
The wp-mixer widget's WirePlumber signal handler calls
Gtk::ToggleButton::set_active()without verifying the widget is still alive. This is either a use-after-free (widgetdestroyed, callback not disconnected) or a signal firing before widget construction completes.
Config
widgets_right = command-output tray notifications wp-mixer battery clock