FS#78160 - [wireplumber] takes 100% of one CPU, crashes, and dumps core

Attached to Project: Arch Linux
Opened by Tassilo Horn (tsdh) - Monday, 10 April 2023, 08:24 GMT
Last edited by Toolybird (Toolybird) - Friday, 12 May 2023, 23:47 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Every so often, the wireplumber process starts taking 100% of one core. htop shows that in that case, usually systemd-coredump is also very busy. And indeed, I seem to have many dumps:

~
❯ coredumpctl list
TIME PID UID GID SIG COREFILE EXE SIZE
Fri 2023-03-31 11:22:12 CEST 1010 1000 1000 SIGSEGV missing /usr/bin/wireplumber -
Fri 2023-03-31 12:32:38 CEST 40691 1000 1000 SIGSEGV missing /usr/bin/wireplumber -
Fri 2023-03-31 13:04:46 CEST 55593 1000 1000 SIGSEGV missing /usr/bin/wireplumber -
Fri 2023-03-31 14:51:18 CEST 62299 1000 1000 SIGSEGV missing /usr/bin/wireplumber -
Mon 2023-04-03 20:49:33 CEST 976 1000 1000 SIGSEGV missing /usr/bin/wireplumber -
Sun 2023-04-09 20:27:10 CEST 932 1000 1000 SIGABRT present /usr/bin/wireplumber 406.1M
Mon 2023-04-10 09:36:58 CEST 919 1000 1000 SIGSEGV present /usr/bin/pipewire 556.5K
Mon 2023-04-10 09:37:05 CEST 920 1000 1000 SIGSEGV present /usr/bin/wireplumber 96.3M
Mon 2023-04-10 09:59:02 CEST 7779 1000 1000 SIGSEGV present /usr/bin/wireplumber 710.0M
Mon 2023-04-10 10:05:42 CEST 15449 1000 1000 SIGSEGV present /usr/bin/wireplumber 1.5M

I have attached three "coredumbctl gdb"..."thread apply all bt full" traces of the last thee functional dumps. The second last only complained about inaccessible memory addresses, so that's not included.

Additional info:
* package version(s): extra/libwireplumber 0.4.14-1, extra/wireplumber 0.4.14-1

Steps to reproduce:
Sadly, I have no recipe. It just happens quite often. I think it only happens when firefox-developer-edition is running but that may be a false claim as that (and emacs and foot) are applications which run basically always. Also, it doesn't necessarily always happen while firefox is the app I'm currently using, e.g., it might be idling around on some other workspace.
   wireplumber-trace.log (17.2 KiB)
   wireplumber-trace2.log (25.6 KiB)
   wireplumber-trace3.log (15.9 KiB)
This task depends upon

Closed by  Toolybird (Toolybird)
Friday, 12 May 2023, 23:47 GMT
Reason for closing:  Upstream
Additional comments about closing:  See comments
Comment by David Runge (dvzrv) - Monday, 10 April 2023, 14:41 GMT
@tsdh: Thanks for the report.

As this (at least currently) does not look like a packaging issue: Have you reported this upstream? I don't think there is much we can do about this crash as a distributor.
Comment by Tassilo Horn (tsdh) - Tuesday, 11 April 2023, 11:42 GMT
@dvzrv Alright, I've reported the issue upstream at https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/443.
Comment by Jan Alexander Steffens (heftig) - Friday, 14 April 2023, 11:03 GMT
Potentially fixed with libcamera 0.0.4-4?
Comment by Tassilo Horn (tsdh) - Friday, 14 April 2023, 12:04 GMT
@heftig I've just updated to that version. We'll see. I didn't get the original error too often, so guess I should run the new version for some weeks without issues before we consider this issue solved.
Comment by Tassilo Horn (tsdh) - Saturday, 15 April 2023, 19:03 GMT
@heftig As you might have seen in the upstream bug report, I've had at least one crash with libcamera 0.0.4-4. Stacktrace is attached there [1], too.

[1] https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/443#note_1869828
Comment by Tassilo Horn (tsdh) - Friday, 12 May 2023, 12:11 GMT
I think this issue can be closed. I haven't had the issue for some weeks (maybe fixed by libcamera-0.0.5) and as said by David, it probably hasn't been a packaging issue anyway.

Loading...