GNOME Bugzilla – Bug 740666
Mutex is never released on one path in GnomeDesktopThumbnailFactory
Last modified: 2014-12-11 00:03:09 UTC
I got this random crash (SIGABRT) in totem 3.14.0-2 with GNOME 3.14 on Debian jessie. I don't recall what I was doing at the time, possibly trying to watch a youtube video or other video embedded into a web page. If the crash dump isn't useful, please close this bug. $ gdb -batch -n -ex bt -ex 'thread apply all bt full' --core /var/crash/1000/18378-1000-1000-6-1416815741-chianamo--usr-bin-totem.core /usr/bin/totem [New LWP 18378] [New LWP 18382] [New LWP 18379] [New LWP 18393] [New LWP 18535] [New LWP 18955] [New LWP 18956] [New LWP 18381] [New LWP 18383] [New LWP 18384] [New LWP 18385] [New LWP 18390] [New LWP 18386] [New LWP 18599] [New LWP 18380] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/totem'. Program terminated with signal SIGABRT, Aborted.
+ Trace 234369
Thread 1 (Thread 0x7f99bf89c9c0 (LWP 18378))
Created attachment 292499 [details] [review] thumbnail: Fix a code path where the mutex is never unlocked Fix one unusual code path where the GnomeDesktopThumbnailFactory’s mutex is not unlocked before the function returns. As well as the usual deadlock issues, this would lead to an abort on shutdown with recent GLib changes, as g_mutex_clear() would be called on the locked mutex, which GLib now (correctly) complains about.
This is a locking bug in libgnome-desktop.
Review of attachment 292499 [details] [review]: Looks good, thanks!
Attachment 292499 [details] pushed as 5b28350 - thumbnail: Fix a code path where the mutex is never unlocked