[pulseaudio-tickets] [Bug 106581] pa_assert_se should not be used with system calls

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat May 19 17:13:04 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=106581

--- Comment #1 from Tanu Kaskinen <tanuk at iki.fi> ---
(In reply to Christopher Yeleighton from comment #0)
> 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] https://linux.die.net/man/3/pthread_mutex_unlock

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20180519/c5aff65a/attachment-0001.html>


More information about the pulseaudio-bugs mailing list