gnubg crashes soon after starting. Attempt to unlock mutex that was not locked

Bug #1346567 reported by crf on 2014-07-21
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gnubg (Ubuntu)

Bug Description

Gnubg crashes after starting.
It didn't use to crash. But it starting crashing after a recent update of Ubuntu (within the second week of July).
The Ubuntu version, as well as one built from the GNU project's sources crash in the same way.

In the terminal there is printed:
 Attempt to unlock mutex that was not locked

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: gnubg 1.02.000-2
ProcVersionSignature: Ubuntu 3.13.0-32.57-generic
Uname: Linux 3.13.0-32-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Jul 21 14:25:16 2014
InstallationDate: Installed on 2012-09-02 (687 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120902)
SourcePackage: gnubg
UpgradeStatus: Upgraded to trusty on 2014-05-09 (73 days ago)

crf (chrisfahlman) wrote :
Michael Petch (mpetch) wrote :


I'm one of the upstream maintainers and it appears someone else reported a similar problem with a recent update. I installed Ubuntu 14.04 from scratch and installed the product and it ran okay.

With that being said a clean environment may be hiding the problem. I'd like you to attach a copy of your gnubgautorc file to this bug or email a copy directly to <email address hidden> . This file is found in in your user directory in a folder called .gnubg . So that would be the file:


(Tilde is your home directory)

After sending me a copy of the file please do the following. Close all copies of GNUbg. Go to your home directory and rename the .gnubg directory to .gnubgold (rename it do not delete it). Run GNU Backgammon again. It should detect that the ~/.gnubg directory doesn't exist and rebuild a new one with default settings. I am curious if this bug still exists if you do this?

Since I can't reproduce this, one theory is that it is a specific setting from an older version of GNUbg is causing the problem. Resetting to defaults will tell me if that is the case. Sending your existing gnubgautorc file allows me to test with the exact settings being used.


crf (chrisfahlman) wrote :

Hi, I renamed the ~/.gnubg folder and reran the GnuBG from the Ubuntu repository, and followed the same procedure for one built myself, but the problem persisted.

crf (chrisfahlman) wrote :
Michael Petch (mpetch) wrote :

Thanks for the files and trying out that test. That rules it out being 3D related and something bad in gnubgautorc that migrated from an old version.

When specifically does it crash? At startup? or do you get the board displayed and are able to play and then it crashes later on?

One thing I can think of trying is running gnubg with the -q option:

gnubg -q

You mentioned you have built from sources. I don't know your tech knowledge but I am wondering if you know or have tried building a debug version (with CFLAGS="-g" option) and run gnubg with gdb. A backtrace from GNUbg when it crashes might tell us something.

crf (chrisfahlman) wrote :
crf (chrisfahlman) wrote :

It crashes soon after startup (a few seconds). No interaction with gnubg is required before the program crashes.

Michael Petch (mpetch) wrote :

Thanks for the backtraces. It became clear when I observed the output that you were using glib from a PPA that was an unofficial repository. Upon looking at your attached dependency list I believe the reason this crashes on your system and not a stock 14.04 is related to this:

libglib2.0-0 2.41.2~git20140714.79e63d4e-0ubuntu1~14.04~ricotz0 [origin: LP-PPA-ricotz-testing]
libglib2.0-data 2.41.2~git20140714.79e63d4e-0ubuntu1~14.04~ricotz0 [origin: LP-PPA-ricotz-testing]

You seem to be using Rico Tzschichholz gnome-testing which can make a system unstable. In particular I have identified the glib entries above since I believe they are the heart of the problem. It appears that there is likely a bug being detected in GNUbg because of new checks that were added to recent versions of glib. This is most likely a GNUbg bug, I would have to investigate further when I get a chance to try the new glib out on a system.

I believe the recent changes to GLib that likely influence this bug is this set of patches (see the part about detecting some mutex bugs):

I believe if you were to downgrade glib back to the official Ubuntu version that GNUbg would run albeit it with a bug that is likely going unnoticed. If you could verify that the official glib works then we have an explanation as to why your system is being affected and not others.

crf (chrisfahlman) wrote :

Yes. I agree with you.

Changed in gnubg (Ubuntu):
status: New → Invalid
status: Invalid → Incomplete
Michael Petch (mpetch) wrote :

If you have an opportunity there are some things you might want to try with the new glib. I don't see an obvious bug in the code besides the possibility of an optimization being done because a memory location is volatile but isn't marked as such. The first thing to try is building from source and doing so without optimizations CFLAGS="-O0" . Does the problem exist?

I'd then like to know the output with it configured with CFLAGS="-DDEBUG_MULTITHREADED" . This will display additional text to the console that might help me out.

Although you have marked the bug as invalid, I have an interest in these last couple tests so I can check our code. It is possible in the future that Ubuntu will use a newer glib and we'll be revisiting this issue again. That is of course if there isn't a bug on the glib side.

Michael Petch (mpetch) on 2014-07-26
Changed in gnubg (Ubuntu):
assignee: nobody → Michael Petch (mpetch)
status: Incomplete → Confirmed
Michael Petch (mpetch) wrote :

I have moved this to confirmed. I am working on a fix. It appears that there has been a real but hidden bug in our code since 2.32 related to locking/unlocking/freeing mutexes. It appears this bug didn't exist on WIN32 and any platform with glib<2.32. Although it is hidden it could be causing unexpected problems.

Michael Petch (mpetch) wrote :

Last night I committed a change to CVS that should resolve this problem. If you could test this latest change out I'd appreciate it.

crf (chrisfahlman) wrote :

I think your change worked. The crash doesn't happen any more. Thank you.

Michael Petch (mpetch) wrote :

If Debian/Ubuntu update to 1.03.000 (or higher) this bug should be fixed

Changed in gnubg (Ubuntu):
status: Confirmed → Fix Committed
Michael Petch (mpetch) on 2014-10-16
Changed in gnubg (Ubuntu):
assignee: Michael Petch (mpetch) → nobody
status: Fix Committed → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnubg - 1.03.001-1

gnubg (1.03.001-1) unstable; urgency=medium

  * New upstream release.
    - Fix crash on termination or stopping an analysis.
    - Fix incorrect mutex management with newer GLIB. (LP: #1346567)
    - Improved external interface that is re-entrant and supports quit and
      version commands. Fix various other issues with this interface.
    - Multiple improvements to the Python support.
    - Add set aliases command to list player names for MAT file import.
    - Improvements to eXtreme Gammon file imports.
    - Display match statistics when a match analysis is completed.
  * Convert the packaging to a proper quilt series of changes to upstream
    instead of building with single-debian-patch.
  * Remove man pages added by the Debian packaging, since these have now
    been incorporated upstream.
  * Remove the strength comment in README.Debian, which is already covered
    sufficiently in the package description.
  * Convert the 16x16 and 32x32 PNG icons to XPM format during the build
    and reference them from the menu file. Thanks to Markus Koschany for
    the report. (Closes: #737914)
  * Drop now-unnecessary dh_builddeb override to use xz compression.
  * Update standards version to 3.9.5 (no changes required).

 -- Russ Allbery <email address hidden> Mon, 25 Aug 2014 11:32:14 -0700

Changed in gnubg (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.