GNOME Bugzilla – Bug 735141
unlocking already-unlocked mutex is unconditionally fatal, which is a regression, sort of
Last modified: 2014-08-27 16:46:20 UTC
In GLib 2.41, incorrectly unlocking a mutex that is already unlocked is unconditionally a fatal error due to changes in Bug #731986. This used to "work" in previous GLib versions, as far as I can see. I am aware that unlocking an already-unlocked mutex is a symptom of getting locking sufficiently wrong that your application can't be reliable, but the pygtk UI module for Debian's reportbug application is one example of real-world code where this breaks: <https://bugs.debian.org/758619>. (I'm going to open a pygtk bug next, because I think the pygtk code in question can't possibly be right.) From Bug #731986 it looks as though the intention had been for the error-checking to be runtime-configurable, but the implementation that was merged has this check unconditionally fatal instead. Should it be using getenv() or the flags set by G_DEBUG or something? I realise that this might well be closed NOTABUG, and that's fine, but I wanted to at least ask.
(In reply to comment #0) > I'm going to open a > pygtk bug next, because I think the pygtk code in question can't possibly be > right. Bug #735142
AFAIR, assuming that unlocking an unlocked mutex isn't fatal is already non-portable — at least, I've had bugs reported about it on non-Linux platforms — so there's "prior art" in that. pthreads also has options to enforce this behaviour as well, but we never opted in to them.
(In reply to comment #0) > From Bug #731986 it looks as though the intention had been for the > error-checking to be runtime-configurable, but the implementation that was > merged has this check unconditionally fatal instead. I suggested it should be configurable because I assumed that the error checking would slow things down (which is why we didn't use the error-checking pthread mutexes before). But Ryan was able to implement it such that it doesn't slow down the "fast path" (when there's no contention), so there was no need to make it configurable.
I agree that this is not a bug. Some of the BSDs use errorcheck mutexes by default, for example, and any code that falls afoul of these new checks would already have been broken there...
(In reply to comment #4) > Some of the BSDs use errorcheck mutexes by > default, for example Indeed, notably FreeBSD (Bug #690470, Bug #678758). I agree with NOTABUG but it's good to have confirmed "yes this is definitely how GLib is intended to work". It turns out there have been pygtk bugs open for this particular case since 2012 (Bug #690470, reported for kFreeBSD, and also involving reportbug).
... er, both mentions of Bug #690470 there should have been 690740.
See as well https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/1344386
See also Bug #735428