After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 735141 - unlocking already-unlocked mutex is unconditionally fatal, which is a regression, sort of
unlocking already-unlocked mutex is unconditionally fatal, which is a regress...
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: gthread
2.41.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-08-21 08:25 UTC by Simon McVittie
Modified: 2014-08-27 16:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon McVittie 2014-08-21 08:25:42 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.
Comment 1 Simon McVittie 2014-08-21 08:47:45 UTC
(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
Comment 2 Emmanuele Bassi (:ebassi) 2014-08-21 09:30:37 UTC
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.
Comment 3 Dan Winship 2014-08-21 13:13:59 UTC
(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.
Comment 4 Allison Karlitskaya (desrt) 2014-08-21 13:52:06 UTC
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...
Comment 5 Simon McVittie 2014-08-21 15:07:48 UTC
(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).
Comment 6 Simon McVittie 2014-08-21 15:09:05 UTC
... er, both mentions of Bug #690470 there should have been 690740.
Comment 7 Allison Karlitskaya (desrt) 2014-08-21 19:29:56 UTC
See as well https://bugs.launchpad.net/ubuntu/+source/gnome-do/+bug/1344386
Comment 8 Simon McVittie 2014-08-27 16:46:20 UTC
See also Bug #735428