https://bugs.kde.org/show_bug.cgi?id=511472
Sergey <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Sergey <[email protected]> --- +1, reproduces here on a different trigger than the original report. System: CachyOS (Arch-based), kernel 7.2.3, PipeWire 1.6.8, WirePlumber 0.5.17, Plasma 6.7.5 (Wayland), KF 6.30.0, Qt 6.11.2, libcanberra 0.30. Standalone repro, no fast user switching needed: 1. systemctl --user stop wireplumber (session manager down; pipewire/pipewire-pulse stay up) 2. Trigger any notification carrying a sound hint, or run the pure-libcanberra equivalent: canberra-gtk-play -f /usr/share/sounds/freedesktop/stereo/bell.oga -> never returns (killed after 10+ minutes in my tests). Observed: the entire shell freezes; SIGTERM is not handled (systemd kills the unit after TimeoutStopSec with SIGKILL). Recovery requires kill -QUIT or a plasmashell restart. Coredump taken on the frozen process (SIGQUIT -> systemd-coredump, gdb, condensed main thread stack): pthread_cond_wait libspa-support.so libasound_module_pcm_pipewire.so snd_pcm_prepare (libasound.so.2) alsa_driver_play (libcanberra-alsa.so) ca_context_play_full (libcanberra.so.0) multi_driver_play (libcanberra-multi.so) ca_context_play_full NotificationManager::Notifications::playSoundHint(QModelIndex const&) NotificationManager::Notifications::qt_metacall QV4::QObjectMethod::callPrecise / Runtime::CallPropertyLookup QQmlNotifier::emitNotify QQmlInstantiatorPrivate::_q_createdItem QQmlDelegateModel::_q_itemsInserted -> QAbstractItemModel::endInsertRows So playSoundHint runs inline in the QML notification-model insertion path, i.e. on the main thread. This looks like the same root cause as the original backtrace, reached through a deterministic trigger. Two additional data points: - CANBERRA_DRIVER=pulse also blocks (the server is reachable, but without the session manager nothing links the stream). CANBERRA_DRIVER=null returns in 0.045 s. So the hang is not specific to the ALSA backend. - Workaround in use here: an external watchdog pings org.kde.plasmashell over D-Bus every 3 s and sends kill -QUIT when it stops answering (coredump + systemd Restart=on-failure recovers the panel in ~15-20 s). I see MR plasma-workspace!6516 ("notificationmanager: move sound playback to worker thread") targets exactly this bug and is still open (needs a rebase, 2 unresolved threads). Is the approach in that MR still the direction you want to take? If it helps, I am willing to test a build with it and report back here. -- You are receiving this mail because: You are watching all bug changes.
