The mutex in question is the one used by pulse's mainloop, which gets
used by pa_threaded_mainloop_lock, pa_threaded_mainloop_unlock and
pa_threaded_mainloop_wait.

As the pulseaudio calls are all asynchronous, gst (pulsesink element)
calls  pa_threaded_mainloop_wait right after calling pulseaudio, so it
can block the thread until pulseaudio returns via callback (which then
calls pa_threaded_mainloop_signal, unblocking the thread).

The mutex is also recursive, allowing many lock and unlock calls to
happen in parallel.

Follows the log when I'm able to reproduce the crash (with the mutex recursive 
count):
Interrupt: Stopping pipeline ...
Execution ended after 0:00:06.840520615
Setting pipeline to PAUSED ...
(thread id: 3069599744) pa_threaded_mainloop_lock -> mutex: 0xb5250e00
(thread id: 3069599744) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3069599744) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3069599744) pa_threaded_mainloop_unlock -> mutex: 0xb5250e00
(thread id: 3069599744) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 3069599744) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
0:00:07.586470308 12439  0x15d1dc0 DEBUG                  pulse 
pulsesink.c:1272:gst_pulseringbuffer_pause:<pulsesink1> Pausing and corking, 
before calling mainloop lock
(thread id: 3069599744) pa_threaded_mainloop_lock -> mutex: 0xb5250e00
(thread id: 3069599744) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3069599744) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
0:00:07.586854770 12439  0x15d1dc0 DEBUG                  pulse 
pulsesink.c:1135:gst_pulsering_set_corked:<pulsesink1> Setting corked state to 1
0:00:07.587025308 12439  0x15d1dc0 DEBUG                  pulse 
pulsesink.c:1142:gst_pulsering_set_corked:<pulsesink1> Calling 
pa_threaded_mainloop_wait (PA_OPERATION_RUNNING)
(thread id: 3069599744) pa_threaded_mainloop_wait -> cond: 0xb52517b8, mutex: 
0xb5250e00
(thread id: 3069599744) pa_cond_wait -> m: 0xb5250e00 (count before wait 1)
(thread id: 3018630240) poll_func lock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3018630240) poll_func unlock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
(thread id: 3018630240) poll_func lock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3018630240) poll_func unlock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
(thread id: 3018630240) poll_func lock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3018630240) poll_func unlock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
(thread id: 3018630240) poll_func lock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3018630240) poll_func unlock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
(thread id: 3018630240) poll_func lock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3018630240) poll_func unlock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
(thread id: 3018630240) poll_func lock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count prev 0)
(thread id: 3018630240) pa_mutex_lock -> m: 0xb5250e00 (count new 1)
(thread id: 3018630240) pa_threaded_mainloop_signal -> cond: 0xb52517b8, 
wait_for_accept: 0, n_waiting: 2
(thread id: 3018630240) pa_cond_signal broadcast -> c 0xb52517b8)
(thread id: 2941641824) pa_cond_wait -> m: 0xb5250e00 (count after wait 1)
(thread id: 2941641824) pa_threaded_mainloop_unlock -> mutex: 0xb5250e00
(thread id: 2941641824) pa_mutex_unlock -> m: 0xb5250e00 (count prev 1)
(thread id: 2941641824) pa_mutex_unlock -> m: 0xb5250e00 (count new 0)
(thread id: 3018630240) poll_func unlock -> mutex: 0xb5250e00
(thread id: 3018630240) pa_mutex_unlock -> m: 0xb5250e00 (count prev 0)
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at 
pulsecore/mutex-posix.c:118, function pa_mutex_unlock(). Aborting.
Aborted (core dumped)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1436162

Title:
  [pulsesink] abort at pthread_mutex_unlock(&m->mutex) == 0' failed at
  pulsecore/mutex-posix.c:118, function pa_mutex_unlock() with libc 2.21

Status in glibc package in Ubuntu:
  Confirmed
Status in gst-plugins-good1.0 package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  current build number: 146
  device name: m75
  channel: ubuntu-touch/vivid-proposed
  last update: 2015-03-24 13:57:03
  version version: 146

  After libc 2.21 landed, pulsesink fails constantly when pausing or
  seeking the active pipeline.

  Abort message:
  Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at 
pulsecore/mutex-posix.c:118, function pa_mutex_unlock(). Aborting.

  This is basically happens when it tries to unlock a mutex that is
  already unlocked.

  This issue doesn't happen with libc 2.19.

  To reproduce the issue:
  GST_DEBUG=*pulse*:5 gst-launch-1.0 playbin uri=file:///tmp/foobar.mp3

  Then when playing, just hit control+c, which will then pause the
  pipeline, causing the crash. The crash happens with most of the times
  you pause or seek the pipeline.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1436162/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to