Pipewire Segmentation Fault on libX11 update

Closed
  • Is something wrong?
#63,218 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
linux, shell
Domain
audio-video-rtc, operating-systems

Research direction

The report names PipeWire 1.6.9, libX11 1.8.14, wlroots based window managers, and Sway, but gives no source files or failing test. Start by checking the reported package updates and PipeWire logs for the X11 I/O error, then try the reproduction steps in a wlroots session. Done means identifying and fixing the cause of the idle crash; the report does not specify a test or expected resolution beyond PipeWire remaining running.

Written by the indexing model from the issue text.

Description

bug needs-testing
Is this a new report?

Yes

System Info

Void 6.18.58_1 x86_64 AuthenticAMD uptodate rrrrm

Package(s) Affected

pipewire-1.6.9_1 libX11-1.8.14_1 libX11-32bit-1.8.14_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

None found, except /r/voidlinux

Expected behaviour

Until now, /usr/bin/pipewire was fairly flexible, and allowed itself to be launched directly from a given wlroots-based WM of choice, aside from being stable overall

Actual behaviour

After updating packages libX11-1.8.14_1 libX11-32bit-1.8.14_1, /usr/bin/pipewire started experiencing severe issues on wlroots-based WMs (Tested and confirmed on sway)

It now has a guaranteed crash when launch is attempted from WM config, wheter directly or through a dedicated script. 3-years old setups that had been stable until now, became utterly non-functional inspite of very different hardware configurations

Output is always similar to this (This was also posted on Reddit, but I have found this error to be recurring in my own logs):

[W][12:54:43.206919] mod.x11-bell | [module-x11-bell.:  321 x11_io_error_handler()] X11 I/O error handler called on display :0
[W][12:54:43.207004] mod.x11-bell | [module-x11-bell.:  162 x11_io_error_exit_handler()] X11 display (:0) has encountered a fatal I/O error
[W][12:54:43.207020] mod.x11-bell | [module-x11-bell.:  321 x11_io_error_handler()] X11 I/O error handler called on display :0
[W][12:54:43.207028] mod.x11-bell | [module-x11-bell.:  162 x11_io_error_exit_handler()] X11 display (:0) has encountered a fatal I/O error
Segmentation fault         pipewire

This error is also encountered when attempting to launch /usr/bin/pipewire through daemonize, as well as manually lauching /usr/bin/pipewire alongside /usr/bin/wireplumber (As it was done in the past) without resorting to files into $HOME/.config/pipewire/pipewire.conf.d/ to do that for you. This suggests not to be a configuration error per se.

The error itself is somewhat difficult to replicate outside of using a WM's own launch routines. Manually ensuring to have launched /usr/bin/pipewire alongside /usr/bin/wireplumber will NOT trigger the error immediately. Indeed, it has been observed for /usr/bin/pipewire not to crash at all if kept into a sort of "KEEP-ALIVE" status where it's constantly being fed an audio source. Leaving the system idle (No standby, or sleep, just idle) however, will eventually guarantee a sort of automated /usr/bin/pipewire crash with an output similar to the above.

Attempting to keep /usr/bin/pipewire alongside /usr/bin/wireplumber as both being launched by a terminal emulator which is kept minimized in foreground, will still eventually lead to the aforementioned error with no appreciable change in behaviour, suggesting there not to be a daemonization problem.

Several users on Reddit have reported this very same concern:

https://www.reddit.com/r/voidlinux/comments/1xeyqqi/pipewire_randomly_crashing_mid_session_voidlinux/
https://www.reddit.com/r/voidlinux/comments/1xfmqb4/closing_steam_crashes_pipewire_waybar/
https://www.reddit.com/r/voidlinux/comments/1xfsvep/a_pipewire_crash_temporary_solution/

Steps to reproduce
  1. You need to be using a wlroots-based WM, and also possibly an XWayland session running
  2. Launch /usr/bin/pipewire alongside /usr/bin/wireplumber whether manually, through a dedicated script, or through the WM's own launching routines
  3. Use wpctl status in a terminal emulator to ensure your pipewire session is actually running properly (It may simply skip to step 5 directly, especially if launching from a WM's own launch routine)
  4. Leave the system idle for a while, or otherwise do any task without constantly feeding /usr/bin/pipewire an audio source
  5. Run wctl status again, and find out that, suddenly, wireplumber reports it cannot anymore connect to pipewire
  6. Utilize pgrep to realize that pipewire is not anymore among running processess (pipewire-pulse may still run in a non-functional state, however)
  7. Check your pipewire logs for errors
Dominant language
Shell
Stars
3.5k
Forks
2.8k
Avg merge
1d 21h
Merged PRs (30d)
302

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from void-linux/void-packages

All issues in void-linux/void-packages

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.