<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - pa_assert_se should not be used with system calls" href="https://bugs.freedesktop.org/show_bug.cgi?id=106581#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - pa_assert_se should not be used with system calls" href="https://bugs.freedesktop.org/show_bug.cgi?id=106581">bug 106581</a> from <a class="email" href="mailto:tanuk@iki.fi" title="Tanu Kaskinen <tanuk@iki.fi>"> Tanu Kaskinen</a> <pre>(In reply to Christopher Yeleighton from <a href="show_bug.cgi?id=106581#c0">comment #0</a>) > I got the following abortion from libpulse0: > > Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at > pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. > > pthread_mutex_unlock is a system call. > System calls can fail for various reasons and it should never be asserted > that they succeed. I'm not convinced that it's that simple. Can you point out a failure case for pthread_mutex_unlock() that isn't a programming error either in pulseaudio or in the application using libpulse? The man page[1] lists the following possible failures: EINVAL The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling. PulseAudio doesn't set PTHREAD_PRIO_PROTECT, so I believe this failure is impossible. EINVAL The value specified by mutex does not refer to an initialized mutex object. Clearly a programming error, so an assertion is appropriate. EAGAIN The mutex could not be acquired because the maximum number of recursive locks for mutex has been exceeded. I don't understand why this is listed as a possible error for pthread_mutex_unlock(), since that function doesn't acquire the mutex. Probably an error in the man page. EPERM The current thread does not own the mutex. A programming error. My guess is that the application is doing something from a wrong thread. > Libraries should not abort their client. Aborting on assertion failures is fine, IMHO. And on out-of-memory conditions. libpulse is hardly the only library doing this. [1] <a href="https://linux.die.net/man/3/pthread_mutex_unlock">https://linux.die.net/man/3/pthread_mutex_unlock</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>