GNOME Bugzilla – Bug 742047
Require Vala 0.26 for Shotwell 0.24 (was: shotwell-0.20.2 freezes during manual import under gnome-3.14)
Last modified: 2016-04-25 19:38:39 UTC
I recently upgraded to gnome-3.14 on Gentoo and noticed that shotwell was hanging a few seconds after displaying the main window. I've been through the debugging process, there are no relevant entries under shotwell.log (because I've had the freeze occur with various different last entries in the log). The gcc when broken shows the following:
+ Trace 234461
After using dconf to disable auto-import and all of the plugins, I manually imported a small directory of about 10 jpg images only, and it still froze (without writing any additional lines to the log file). I've rebuild shotwell, gexiv2 and a few others from source several times because other people encountering freezes suggested that might be a problem. I've also uninstalled gstreamer-0.10, so I'm now only using gstreamer-1.4.5, and still no luck. I'm happy to provide more information or run tests/patches, just let me know how I can help resolve this...
I have to wonder if this is due to the change to use futexes if GLib is running on Linux. (We saw this in Geary recently, bug #737811.) I've pushed a potential fix to wip/742047-mutex. Is it possible for you to build and test it?
Hiya, no I'm afraid that hasn't helped (built both as a patch on 0.20.2 and also direct from the wip/742047-mutex branch). The gdb trace looks that same as before the patch. I'm happy to try other patches, or builds with debugging statements in, if any of that will help?
After adding rudimentary debugging statements, it appears that the code enters the monitor.wait(mutex) statement, never to be seen again! Unfortunately, that's where my detective skills let me down. I've tried to trace through how the monitor stops monitoring, and it seems to be on trigger() which gets fired by semaphore.notify(), but I don't know vala enough to tell which semaphore's waiting and then not getting notified...
Hello Jim, I have tested the branch wip/742047-mutex and it is still not working. I'm running unstable gentoo linux with gnome 3.14 as well. I'm looking forward to test anything needed.
I can confirm this bug with shotwell-0.20.2, glib-2.42.1. I'm on Gentoo and I'm not using GNOME. After picking a directory with under ten JPGs and clicking «Import in place», Shotwell simply hangs. My backtrace seems to be identical: Program received signal SIGINT, Interrupt. 0x00007ffff4173289 in syscall () from /lib64/libc.so.6 (gdb) bt full
+ Trace 234554
I'm not observing any relevant error messages in shotwell.log: L 23691 2015-01-16 00:23:56 [CRT] Directory NikonPreview: Next pointer is out of bounds; ignored. L 23691 2015-01-16 00:23:56 [CRT] Directory NikonPreview: Next pointer is out of bounds; ignored. L 23691 2015-01-16 00:23:56 [CRT] Directory NikonPreview: Next pointer is out of bounds; ignored. L 23691 2015-01-16 00:23:56 [CRT] Directory NikonPreview with 8224 entries considered invalid; not read.
Hmmmmm, so far all the reporters are running Gentoo... It's difficult to tell if that's a coincidence or not, but it might be worth looking into?
Or maybe this version simply hasn't reached many users in other distros yet.
Hello, I've find out that the problem begins when I upgrade glib from version 2.40.2 to 2.42.1. Since in gentoo glib-2.42.1 is a gnome 3.14 dependency, it is not possible to just downgrade it to 2.40.2 while running 3.14. Hope this helps, but I have no idea how to fix that.
I've tried glib-2.42.0, and that suffers the same problem, so if it is glib, it suggests it was a change between 2.42.0 and 2.40.2, but according to the change log most of the changes are trivial [1]. All changes in this release are trivial in nature. - introspection warning fixes - g_application_add_main_option now uses an enum instead of an 'int' for the type of a parameter - added a G_OPTION_FLAG_NONE so that people don't need to use 0 - gresource: Use GError in more places - gresource commandline tool: improve extraction from multiple sections - GSource now takes the context lock (if any) in g_source_set_name() - new documentation to clarify the use of some APIs related to GVariant, GSource, GApplication - other minor updates to docs * Bugs fixed 736683 Thread safety issues with g_main_context_find_source_by_id 736975 [patch] please document that GVariant serialization needs an out-of-band length field So the best I can guess is the thread safety issue or the GSource taking a context lock, but I don't know enough about Glib to figure out which of those might be causing the problem... [1] http://ftp.gnome.org/pub/GNOME/sources/glib/2.42/glib-2.42.0.news
Ok, well I just tried master with vala-0.26.1 (and glib-2.42.1) and it's now importing everything just fine. I compiled master again with vala-0.24 and it failed, so it looks like it's a vala/glib issue that's been resolved in 0.26.1. I also noticed that now, none of my videos have thumbnails whereas previously they did, but either way, I'm glad I've got a working shotwell again. 5:)
Yep, rebuilding shotwell with vala-0.26.1/glib-2.42.1 fixes the import freezing issue.
I've yet to reproduce this, but it does sound like newer versions of Vala solve this problem. Unfortunately, we can't require Vala 0.26 at this moment because the next release of Shotwell has to work on Utopic, which is at 0.24 -- but has the older version of GLib, which doesn't have the problem. I'm retitling this ticket to require 0.26 in the release after Shotwell 0.22.
It looks like the latest development version requires vala 0.28.0 or higher, so could this be closed?
(In reply to Jeff Ames from comment #13) > It looks like the latest development version requires vala 0.28.0 or higher, > so could this be closed? Yep