Bug 796162 – SIGPIPE when playing notification sound

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 796162 - SIGPIPE when playing notification sound


Summary:	SIGPIPE when playing notification sound


Status:	RESOLVED INVALID

Product:	GStreamer
Classification:	Platform
Component:	dont know
Version:	1.14.0
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	git master
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2018-05-16 08:11 UTC by Albert Astals Cid
Modified:	2018-09-19 21:02 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Albert Astals Cid 2018-05-16 08:11:54 UTC

I can reproduce this 100% by making Okular produce two sound notifications (not very quickly one after the other) 

I'll be reported this to pulseaudio in https://bugs.freedesktop.org/show_bug.cgi?id=106540

Thread 21 "queue0:src" received signal SIGPIPE, Broken pipe.

+ Trace 238618

Thread 1 (Thread 0x7ffff7f8de80 (LWP 27699))

#0 __pthread_mutex_lock_full
#1 pa_mutex_lock
at pulsecore/mutex-posix.c line 90
#2 pa_threaded_mainloop_lock
at pulse/thread-mainloop.c line 180
#3 gst_pulsesink_get_time
at pulsesink.c line 2024
#4 gst_audio_clock_get_internal_time
at gstaudioclock.c line 161
#5 gst_clock_get_internal_time
at gstclock.c line 1043
#6 gst_clock_get_time
at gstclock.c line 1083
#7 gst_base_sink_get_position
at gstbasesink.c line 4691
#8 default_element_query
at gstbasesink.c line 4819
#9 gst_audio_base_sink_query
at gstaudiobasesink.c line 502
#10 gst_element_query
at gstelement.c line 1963
#11 bin_query_position_fold
at gstbin.c line 4141
#12 gst_iterator_fold
at gstiterator.c line 617
#13 bin_iterate_fold
at gstbin.c line 4258
#14 gst_bin_query
at gstbin.c line 4378
#15 gst_element_query
at gstelement.c line 1963
#16 bin_query_position_fold
at gstbin.c line 4141
#17 gst_iterator_fold
at gstiterator.c line 617
#18 bin_iterate_fold
at gstbin.c line 4258
#19 gst_bin_query
at gstbin.c line 4378
#20 gst_element_query
at gstelement.c line 1963
#21 bin_query_position_fold
at gstbin.c line 4141
#22 gst_iterator_fold
at gstiterator.c line 617
#23 bin_iterate_fold
at gstbin.c line 4258
#24 gst_bin_query
at gstbin.c line 4378
#25 gst_element_query
at gstelement.c line 1963
#26 bin_query_position_fold
at gstbin.c line 4141
#27 gst_iterator_fold
at gstiterator.c line 617
#28 bin_iterate_fold
at gstbin.c line 4258
#29 gst_bin_query
at gstbin.c line 4378
#30 gst_element_query
at gstelement.c line 1963
#31 bin_query_position_fold
at gstbin.c line 4141
#32 gst_iterator_fold
at gstiterator.c line 617
#33 bin_iterate_fold
at gstbin.c line 4258
#34 gst_bin_query
at gstbin.c line 4378
#35 0x00007fffaf372cce in
#36 gst_element_query
at gstelement.c line 1963
#37 gst_element_query_position
at gstutils.c line 2435
#38 0x00007fffc6c5f6a1 in
#39 0x00007fffc6c5053f in
#40 0x00007fffc6c5449f in
#41 QMetaObject::activate(QObject*, int, int, void**)
#42 QTimer::timeout(QTimer::QPrivateSignal)
#43 QTimer::timerEvent(QTimerEvent*)
#44 QObject::event(QEvent*)
#45 QApplicationPrivate::notify_helper(QObject*, QEvent*)
#46 QApplication::notify(QObject*, QEvent*)
#47 QCoreApplication::notifyInternal2(QObject*, QEvent*)
#48 QTimerInfoList::activateTimers()
#49 0x00007ffff45bfe72 in
#50 g_main_context_dispatch
#51 0x00007fffee6575b1 in
#52 g_main_context_iteration
#53 QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
#54 0x00007fffe8c92482 in
#55 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
#56 QDialog::exec()
#57 KMessageBox::createKMessageBox(QDialog*, QDialogButtonBox*, QIcon const&, QString const&, QStringList const&, QString const&, bool*, QFlags<KMessageBox::Option>, QString const&, QMessageBox::Icon)
#58 KMessageBox::createKMessageBox(QDialog*, QDialogButtonBox*, QMessageBox::Icon, QString const&, QStringList const&, QString const&, bool*, QFlags<KMessageBox::Option>, QString const&)
#59 0x00007ffff68e4fb6 in
#60 KMessageBox::information(QWidget*, QString const&, QString const&, QString const&, QFlags<KMessageBox::Option>)
#61 0x00007fffda9eab85 in
#62 0x00007ffff45a15a4 in
#63 QObject::event(QEvent*)
#64 QApplicationPrivate::notify_helper(QObject*, QEvent*)
#65 QApplication::notify(QObject*, QEvent*)
#66 QCoreApplication::notifyInternal2(QObject*, QEvent*)
#67 QTimerInfoList::activateTimers()
#68 0x00007ffff45bfe72 in
#69 g_main_context_dispatch
#70 0x00007fffee6575b1 in
#71 g_main_context_iteration
#72 QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
#73 0x00007fffe8c92482 in
#74 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
#75 QCoreApplication::exec()
#76 0x000055555555f685 in
#77 __libc_start_main
#78 _start

Comment 1 Tim-Philipp Müller 2018-05-16 08:19:04 UTC

Thanks for the bug report.

Not sure if this is a GStreamer issue. Looks to be in pulseaudio or libpulse, rather.

I suspect the server died when this happens?

Comment 2 Albert Astals Cid 2018-05-16 08:24:37 UTC

I opened it here because from the way packages where updated on my distro seems to be triggered by the new gstreamer version (doesn't mean that gstreamer is the one at fault, of course).

If you mean the pulseaudio process, no it stays up just fine after the crash.

Comment 3 Tanu Kaskinen 2018-05-23 10:53:44 UTC

(I'm from PulseAudio, not a GStreamer developer.)

Based on the backtrace, the crash seems to happen, because pa_mainloop tries to write to an internal pipe that has been closed. The pipe is closed only in pa_mainloop_free(), so it seems that the mainloop is being used after freeing it.

pulsesink uses pa_threaded_mainloop, so pa_mainloop_free() is called from pa_threaded_mainloop_free(). There are a couple of calls to that in pulsesink.c. The crash happens in gst_pulseringbuffer_commit(). Is it possible that gst_pulseringbuffer_commit() is called after a pa_threaded_mainloop_free() call? One of those free() calls has a "mainloop = NULL" assignment right after it, and that should make gst_pulseringbuffer_commit() crash earlier if the free() call is the problem. The other free() call is done when starting the mainloop fails, so it's unlikely that gst_pulseringbuffer_commit() could be called in that situation.

Now I noticed that there's a thread created by pa_threaded_mainloop running. Assuming that there aren't multiple pa_threaded_mainloops in use by the application, pa_threaded_mainloop_free() has certainly not been called. That raises the question: why does the internal wakeup pipe seem to be closed? Nobody else has access to it than pa_mainloop, and it doesn't close the pipe except when freeing the mainloop. Why would the pipe close by itself?

Comment 4 Albert Astals Cid 2018-06-04 23:09:18 UTC

Is there anything i can do to help debug this? Because i'm getting more and more crashes being reported with this backtrace.

Comment 5 Nicolas Dufresne (ndufresne) 2018-06-04 23:16:07 UTC

Probably that just masking SIGPIPE will solve your issue. It will then error in the code, which will be ignored if pulling down the pipeline.

Comment 6 Albert Astals Cid 2018-09-19 21:02:18 UTC

So it seems it was actually a bug in okular, sorry for the noise :(