radiotray crashed with "Attempt to unlock mutex that was not locked"

Bug #1359564 reported by acllos on 2014-08-21
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
radiotray (Ubuntu)
Undecided
Unassigned

Bug Description

after 15/august/2014 updates, radiotray crashes while trying to initialize in the traybar (of mate-desktop).
the crash appears to be gtk2/pygtk related:
in IA__gtk_main () at /build/buildd/gtk+2.0-2.24.24/gtk/gtkmain.c:1270
is a call to GDK_THREADS_LEAVE

if (g_main_loop_is_running (main_loops->data))
    {
      GDK_THREADS_LEAVE ();

which in turn triggers a call to g_mutex_unlock_slowpath.
it appears that in the last glib(s) (2.41+) the gmutex implementation was rewritten and there's a check now on whatever the mutex was already locked or already unlocked ("Attempt to unlock mutex that was not locked").

so, many superfluous but otherwise harmless calls to unlock a gmutex are now causing crashes, and radiotray in combination with the latest pygtk/libgtk2/glib appears to be such a case

ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: radiotray 0.7.3-1ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-9.14-generic 3.16.1
Uname: Linux 3.16.0-9-generic x86_64
ApportVersion: 2.14.6-0ubuntu2
Architecture: amd64
CrashCounter: 1
Date: Thu Aug 21 07:40:16 2014
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/radiotray
ExecutableTimestamp: 1368129423
InstallationDate: Installed on 2014-08-19 (1 days ago)
InstallationMedia: Ubuntu MATE 14.10 "Utopic Unicorn" - Alpha amd64 (20140731)
InterpreterPath: /usr/bin/python2.7
PackageArchitecture: all
ProcCmdline: /usr/bin/python /usr/bin/radiotray
ProcCwd: /usr/lib/python2.7/dist-packages/radiotray
Signal: 6
SourcePackage: radiotray
StacktraceTop:
 raise () from /lib/x86_64-linux-gnu/libc.so.6
 abort () from /lib/x86_64-linux-gnu/libc.so.6
 g_mutex_unlock_slowpath (mutex=<optimized out>, prev=<optimized out>) at /build/buildd/glib2.0-2.41.2/./glib/gthread-posix.c:1327
 IA__gtk_main () at /build/buildd/gtk+2.0-2.24.24/gtk/gtkmain.c:1270
 _wrap_gtk_main (self=<optimized out>) at /build/buildd/pygtk-2.24.0/gtk/gtk.override:1240
Title: radiotray crashed with SIGABRT in raise()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

acllos (accountlostin) wrote :
acllos (accountlostin) on 2014-08-21
description: updated
description: updated
description: updated

StacktraceSource:
 #0 0x00007fab76e1a117 in ?? ()
 #1 0x00007fab76e1b808 in ?? ()
 #2 0x0000000000000020 in ?? ()
 #3 0x0000000000000000 in ?? ()
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()

Changed in radiotray (Ubuntu):
status: New → Invalid

Thank you for your report!

However, processing it in order to get sufficient information for the
developers failed (it does not generate a useful symbolic stack trace). This
might be caused by some outdated packages which were installed on your system
at the time of the report:

libpython2.7-stdlib version 2.7.8-4 required, but 2.7.8-5 is available
libpython2.7 version 2.7.8-4 required, but 2.7.8-5 is available
libc6 version 2.19-4ubuntu1 required, but 2.19-4ubuntu2 is available
libuuid1 version 2.25-8ubuntu1 required, but 2.25-8ubuntu3 is available
python2.7-minimal version 2.7.8-4 required, but 2.7.8-5 is available
outdated debug symbol package for python2.7-minimal: package version 2.7.8-5 dbgsym version 2.7.8-4

Please upgrade your system to the latest package versions. If you still
encounter the crash, please file a new report.

Thank you for your understanding, and sorry for the inconvenience!

tags: removed: need-amd64-retrace
acllos (accountlostin) on 2014-08-21
description: updated
acllos (accountlostin) wrote :

*gosh*. I did update the system after collecting the coredump, but the result was still the same.
I provided a Stacktrace.txt complete with line references, this should be valid IMHO

Changed in radiotray (Ubuntu):
status: Invalid → New
acllos (accountlostin) on 2014-08-30
information type: Private → Public
acllos (accountlostin) wrote :

psensors ran in a similar problem, which appears to be a bug in GTK itself making it incompatible with glib >= 2.41 (both from gnome...)
https://bugs.launchpad.net/ubuntu/+source/psensor/+bug/1346299

it was solved by the packager by avoiding a call to the now deprecated gdk_threads_init which triggered the bug for unknown reasons.

radiotray too attempts to call "gtk.gdk.threads_init", in src/SysTray.py:185

    def run(self):
        gtk.gdk.threads_init()
        gtk.main()

which is also present in the bt.
maybe avoiding to call gtk.gdk.threads_init() would solve the problem for radiotray too? I'll try to create a patch file.
and, shouldn't a bug opened against GTK?

acllos (accountlostin) wrote :

attaching a tentative patch.

The attachment "tentative patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch

radiotray too attempts to call "gtk.gdk.threads_init", in src/SysTray.py:185

    def run(self):
        gtk.gdk.threads_init()
        gtk.main()

Going into SysTray.py and removing the line gtk.gdk.threads_init() from the code above allows RadioTray to run perfectly on my system.

acllos (accountlostin) wrote :

thanks for your feedback.
so, avoiding that call appears to be a valid workaround, however the bug lies in libgtk2 (it seems to be a latent bug which emerged only with the new, stricted glib).
someone should open a bug against it as it seems to affect any gtk application calling gdk_threads_init.

in the meantime, may I ask you to state that the bug affects you too? https://bugs.launchpad.net/ubuntu/+source/radiotray/+bug/1359564/+affectsmetoo

(so at least it would become 'confirmed' and maybe some dev will look at it)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in radiotray (Ubuntu):
status: New → Confirmed
Xavier Guillot (valeryan-24) wrote :

Commenting the 185th line resolves the bug for me, too. I added me as affected to confirm it.

Someone reported the bug upstream - https://bitbucket.org/carlmig/radio-tray/issue/220/crashed-with-attempt-to-unlock-mutex-that

Problem is that Radiotray developer didn't post any commit since April, I hope he's well - perhaps Debian or Ubuntu packager could correct it directly ?

acllos (accountlostin) wrote :

thanks for your cooperation.

i stumbled into this trying to help a forum user with radiotray problems (didn't play some radios because of dropped gstreamer0.10-ffmpeg package from ubuntu).

after he manually patched and compiled it as I suggested, he started having this error.
to exculpate myself I tried findind the cause of the crash and reported this bug, which doesn't directly affect me as I'm not a radiotray user.

I think I/we may have more fortune reporting a complete patch to the debian project, which has real, flesh packagers assigned to it (Elías Alejandro Año Mendoza <email address hidden>) who will probably accept or fix it.

the updated debian package would then be imported into ubuntu thus fixing the problem here too.

I'm not used to it, but I'll try to create a patch to be applied when building the deb.

Xavier Guillot (valeryan-24) wrote :

If it can help, I was initially affected by this other bug : radiotray crashed with SIGABRT in gtk_main()
https://bugs.launchpad.net/ubuntu/+source/radiotray/+bug/1344043

in which a link was given to here with the solution (edit SysTray.py and comment line 185).

acllos (accountlostin) wrote :

I'm planning to submit this to debian, is this the correct way of doing so?

Vitalii (archosss) on 2015-09-01
information type: Public → Public Security
information type: Public Security → Public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers