desktop-packages team mailing list archive

[Ricardo Salveti <rsalveti@xxxxxxxxxxxx>]

It seems the issue only happens when at least 2 threads are waiting for
the wait condition (that gets triggered by pa_threaded_mainloop_signal).
When I'm unable to make it to crash, it always shows only one thread
waiting the signal.

So my current theory is that there might be issues when calling
pthread_cond_wait on more than one thread at the same time (maybe when
increasing/decreasing the mutex count).

-- 
You received this bug notification because you are a member of Desktop
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