Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jul 2013 12:53:28 +0200
From:      Koop Mast <>
To:        Joe Marcus Clarke <>
Subject:   Re: Mutexes and error checking
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 07/23/13 18:18, Joe Marcus Clarke wrote:
> On 7/23/13 11:43 AM, Martin Simmons wrote:
>>>>>>> On Sun, 21 Jul 2013 16:52:08 -0400, Joe Marcus Clarke said:
>>> The specifics are this.  There are some GNOME/GTK+/GLib apps that are
>>> crashing now that GLib checks the return of pthread_mutex_unlock() in
>>> g_mutex_unlock().  While we can workaround this in GLib by simply
>>> nop'ing the EPERM return, we'd like to pursue something that may be a
>>> bit more manageable for those apps written for Linux that do not use GLib.
>> Which apps are broken and why can't they be fixed?
> Koop, do you have a complete list?  The one that was reported to me was
> sonata (a Python app).  I have not yet traced down the offending code as
> I was curious why Linux was not failing, and this appears to be why.
> Joe

I only am aware of audio/sonata currently. I can remember seeing a 
similar error once or twice before. So while looking for more failures 
like the one in sonata, I ran into a fix for sonata in the OpenBSD ports 
[1].  . I also found the same solution was fixed in lxpanel [2]. The fix 
is to use the |GDK| mutual exclusion lock to prevent more then one 
thread being active [3].

With this I can fix the few ports that exhibit this problem and we don't 
have to change anything in base.



>>> Again, I'm not arguing the voracity of the 3rd party app code, just the
>>> discrepancy between Linux and Solaris compared to FreeBSD.
>> Note that unlocking an unlocked normal mutex on Linux (glibc) does *not* work,
>> but leaves it in a subtly inconsistent state.  Therefore bugs like the one you
>> reported to the GNOME Bugzilla
>> ( should be fixed, not
>> ignored by hiding the error status.
>> __Martin

Want to link to this message? Use this URL: <>