| Summary: | pa_assert_se should not be used with system calls | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Christopher Yeleighton <giecrilj> |
| Component: | clients | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED MOVED | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | lennart |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Windows (All) | ||
| URL: | https://bugs.kde.org/show_bug.cgi?id=394425 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Christopher Yeleighton
2018-05-19 16:54:34 UTC
(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 -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/371. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.