Bug 1900339 - pavucontrol segfault when plugging in headset with pipewire-pulse server
Summary: pavucontrol segfault when plugging in headset with pipewire-pulse server
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: pipewire
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Wim Taymans
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-22 11:51 UTC by Dominique Martinet
Modified: 2021-01-22 10:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-22 10:54:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dominique Martinet 2020-11-22 11:51:21 UTC
Description of problem:

pavucontrol segfaults when plugging/unplugging headset with pipewire-pulse server

Version-Release number of selected component (if applicable):

pavucontrol-4.0-5.fc33.x86_64
pipewire-0.3.16-1.fc33.x86_64

How reproducible:

always

Steps to Reproduce:
1. start pipewire-pulse/make it take over pulse use socket
2. start pavucontrol
3. plug or unplug headset

Actual results:
segfault

Expected results:
doesn't

Additional info:
This is probably a bug in pavucontrol really but means the behaviour isn't identical with pulse.

segfault trace:
       Message: Process 2348008 (pavucontrol) of user 1000 dumped core.
                
                Stack trace of thread 2348008:
                #0  0x00007f339b4ebab2 __strcmp_avx2 (libc.so.6 + 0x15dab2)
                #1  0x00007f339b78252c context_get_card_info_callback (libpulse.so.0 + 0x2552c)
                #2  0x00007f339a72d0a3 run_action (libpulsecommon-13.99.so + 0x420a3)
                #3  0x00007f339a72da9f pa_pdispatch_run (libpulsecommon-13.99.so + 0x42a9f)
                #4  0x00007f339b77002f pstream_packet_callback (libpulse.so.0 + 0x1302f)
                #5  0x00007f339a73255d do_read (libpulsecommon-13.99.so + 0x4755d)
                #6  0x00007f339a7340df do_pstream_read_write (libpulsecommon-13.99.so + 0x490df)
                #7  0x00007f339b7b578e dispatch_func (libpulse-mainloop-glib.so.0 + 0x278e)
                #8  0x00007f339b80afd7 g_main_context_dispatch (libglib-2.0.so.0 + 0x51fd7)
                #9  0x00007f339b85bd88 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2d88)
                #10 0x00007f339b80841f g_main_context_iteration (libglib-2.0.so.0 + 0x4f41f)
                #11 0x00007f339afa13e5 g_application_run (libgio-2.0.so.0 + 0xd53e5)
                #12 0x00007f339b3b61a2 __libc_start_main (libc.so.6 + 0x281a2)
                #13 0x0000557f66cc1cde _start (pavucontrol + 0x2acde)
                
                Stack trace of thread 2348009:
                #0  0x00007f339b484a0f __poll (libc.so.6 + 0xf6a0f)
                #1  0x00007f339b85bd1e g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2d1e)
                #2  0x00007f339b80841f g_main_context_iteration (libglib-2.0.so.0 + 0x4f41f)
                #3  0x00007f339b80a031 glib_worker_main (libglib-2.0.so.0 + 0x51031)
                #4  0x00007f339b837ede g_thread_proxy (libglib-2.0.so.0 + 0x7eede)
                #5  0x00007f339aade3f9 start_thread (libpthread.so.0 + 0x93f9)
                #6  0x00007f339b48fb03 __clone (libc.so.6 + 0x101b03)
                
                Stack trace of thread 2348010:
                #0  0x00007f339b484a0f __poll (libc.so.6 + 0xf6a0f)
                #1  0x00007f339b85bd1e g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2d1e)
                #2  0x00007f339b80a6ab g_main_loop_run (libglib-2.0.so.0 + 0x516ab)
                #3  0x00007f339afd46b6 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x1086b6)
                #4  0x00007f339b837ede g_thread_proxy (libglib-2.0.so.0 + 0x7eede)
                #5  0x00007f339aade3f9 start_thread (libpthread.so.0 + 0x93f9)
                #6  0x00007f339b48fb03 __clone (libc.so.6 + 0x101b03)
                
                Stack trace of thread 2348027:
                #0  0x00007f339b48a50d syscall (libc.so.6 + 0xfc50d)
                #1  0x00007f339b856a38 g_cond_wait_until (libglib-2.0.so.0 + 0x9da38)
                #2  0x00007f339b7dc341 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x23341)
                #3  0x00007f339b7dc4c2 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x234c2)
                #4  0x00007f339b83aab9 g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x81ab9)
                #5  0x00007f339b837ede g_thread_proxy (libglib-2.0.so.0 + 0x7eede)
                #6  0x00007f339aade3f9 start_thread (libpthread.so.0 + 0x93f9)
                #7  0x00007f339b48fb03 __clone (libc.so.6 + 0x101b03)


---------------
I've also had another assertion failure, not sure when that happened (suspend/resume perhaps?)
ERROR:streamwidget.cc:94:void StreamWidget::setVolume(const pa_cvolume&, bool): assertion failed: (v.channels == channelMap.channels)
Bail out! ERROR:streamwidget.cc:94:void StreamWidget::setVolume(const pa_cvolume&, bool): assertion failed: (v.channels == channelMap.channels)
Aborted (core dumped)


letting you reassign if you feel it's more appropraite over there.

Comment 1 Wim Taymans 2021-01-22 10:54:33 UTC
I believe this is fixed in recent versions. Reopen if not.


Note You need to log in before you can comment on or make changes to this bug.