[Bug 796162] SIGPIPE when playing notification sound

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796162

Tanu Kaskinen <tanuk at iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tanuk at iki.fi

--- Comment #3 from Tanu Kaskinen <tanuk at iki.fi> ---
(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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.