[Shotwell] Call for testing!

Wed Dec 16 20:35:26 UTC 2009

Jim Nelson wrote:
> We invite everyone to run this new version of Shotwell through its
> paces.  As always, we welcome your bug reports, comments, and
> suggestions, either here or on our Trac ticketing system
> (http://trac.yorba.org).  We'd *really* like to hear about any
> crashers or critical bugs you may uncover.  It's our hope to shake out
> as many as possible before ship.

I kicked its tires some more today.

* If you run "./configure --help" it says that "--release" is the default
but this is not the case (you set BUILD_RELEASE=1 in the makefile and then
after that you include configure.mk which might override, but in the end
you have hardcoded -g for VALAFLAGS). Debug info is nice but valac also
generates #line directives in "-g" mode which makes gdb jump back and
forth between .c and .vala files so I prefer to configure in release mode
without -g and then just build Shotwell explicitly with:

  CFLAGS="-g3 -O0" make -j4

This is why I think it would be nice if --release suppressed the -g param.

* Suppose a user repeatedly runs "Import From Folder" on his home folder
hoping that the duplicate detector will ensure his photo collection
is kept tidy anyway. Today, after a while he will notice that there a
lot of duplicates in his photo collection anyway and they will be called
stuff like "thumb000000000000038d.jpg" etc. What has happened is that
Shotwell has been scanning "~/.shotwell/thumbs" and imported stuff from
there. I suggest this particular dir should be suppressed from scanning.

* When "Import From Folder" runs out of disk space, then Shotwell will
sometimes SIGABRT's with this error:

  ** ERROR **: LibraryFiles.vala:34: Unable to create photo library directory BLAH

I'd ask you to re-consider this one and change the error() to something
a bit more graceful since out of disk is not unreasonable for first time
users doing big imports into Shotwell (especially if you have
"Copy to ~/Pictures" on).

* When I select "Import from folder" on my homedir (which is 13GB with
tons of small files and tons of folders) the "Import From Folder" dialog
remains open for minutes while my HDD works intensely (I suppose it's
making a list of all the photos to import). It would be nicer if that
dialog disappeared before the HDD scanning starts (possible you're calling
hide early enough but maybe the GTK mainloop is not given time to process
that hide message?).

* It would be nice with a progress bar for long running imports. For large
imports Shotwell currently shows all black in the "Importing..." page and
appears to do nothing for several minutes before the images starts to swizzle by.

* Just for kicks I ran "Import From Folder" on my ~/src folder which has
the mozilla tree, the kernel code etc. I was thinking this would be nice
stress test to see if Shotwell ignores unexpected file types and still finds
the images. First I noticed that Shotwell seems to spend time processing
non-images, look at the stack snippet below for example. Why call
batch_import_import_file for a non-image file at all?

#0  library_photo_import (file=0x114e0e0, import_id=0x11d58d8, photo=0x7fffffffdb40) at src/Photo.c:4180
#1  0x00000000004a3c6b in batch_import_import_file (self=0x113eca0, file=0x7fffdc0b6560, copy_to_library=1) at src/BatchImport.c:1481
#2  0x00000000004a2b82 in batch_import_import (self=0x113eca0, job=0x11fb640, file=0x7fffdc0b6560, copy_to_library=1, id=0x1140860 "/home/mnemo/src/mozilla/content/base/public/Makefile.in") at src/BatchImport.c:1193
#3  0x00000000004a2f90 in batch_import_import_dir (self=0x113eca0, job=0x11fb640, dir=0x11cb160, copy_to_library=1) at src/BatchImport.c:1258
#4  0x00000000004a2b67 in batch_import_import (self=0x113eca0, job=0x11fb640, file=0x11cb160, copy_to_library=1, id=0x110bb50 "/home/mnemo/src/mozilla/content/base/public") at src/BatchImport.c:1188
#5  0x00000000004a278d in batch_import_perform_import (self=0x113eca0) at src/BatchImport.c:1150
#6  0x00000000004a21ba in _batch_import_perform_import_gsource_func (self=0x113eca0) at src/BatchImport.c:1086
#7  0x00007ffff2359bbe in g_main_dispatch (context=0x7d0730) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:1960

Note especially what happens when the dupe checker finds a bunch of 4GB .mvk files.
To quote the Shotwell code "// if no EXIF data, then do full MD5 match" :-)
For example, put 10-20 4GB .mvk files into a folder and try to let Shotwell do
"Import From Folder" on it, while you fire up "iotop" next to it. Lot's of bytes
flying both on and off the disk it seems.

* Finally, after I let it chew a while on importing the full mozilla source tree I got this SIGABRT crash:

**
ERROR:Photo.vala:1116:transformable_photo_load_raw_pixbuf: assertion failed: (dimensions_approx_equals (&scaled_image, (_tmp5_ = (dimensions_for_pixbuf (pixbuf, &_tmp4_), _tmp4_), &_tmp5_), TRANSFORMABLE_PHOTO_SCALING_FUDGE))

#1  0x00007ffff1de0f50 in *__GI_abort () at abort.c:92
#2  0x00007ffff237f540 in IA__g_assertion_message (domain=<value optimized out>, file=<value optimized out>, line=<value optimized out>, func=0x4d7be0 "transformable_photo_load_raw_pixbuf", message=0x4cfc680 "assertion failed: (dimensions_approx_equals (&scaled_image, (_tmp5_ = (dimensions_for_pixbuf (pixbuf, &_tmp4_), _tmp4_), &_tmp5_), TRANSFORMABLE_PHOTO_SCALING_FUDGE))") at /build/buildd/glib2.0-2.22.2/glib/gtestutils.c:1317
#3  0x00007ffff237fab0 in IA__g_assertion_message_expr (domain=0x0, file=0x4d6088 "Photo.vala", line=1116, func=0x4d7be0 "transformable_photo_load_raw_pixbuf", expr=<value optimized out>) at /build/buildd/glib2.0-2.22.2/glib/gtestutils.c:1328
#4  0x00000000004594c8 in transformable_photo_load_raw_pixbuf (self=<value optimized out>, scaling=0x7fffffffd710, exceptions=<value optimized out>, no_copy=1, scaled_image=<value optimized out>, error=0x7fffffffd658)
#5  transformable_photo_get_raw_pixbuf (self=<value optimized out>, scaling=0x7fffffffd710, exceptions=<value optimized out>, no_copy=1, scaled_image=<value optimized out>, error=0x7fffffffd658) at Photo.vala:1163
#6  0x0000000000459b3c in transformable_photo_get_pixbuf_with_exceptions (self=0x4aec8d0, scaling=<value optimized out>, exceptions=<value optimized out>, error=<value optimized out>)
#7  0x000000000045a276 in transformable_photo_real_get_pixbuf (base=0x4aec8d0, scaling=0x7fffffffd710, error=0x7fffffffd758)
#8  0x00000000004293ac in _thumbnail_cache_import (self=0x803a00, photo_id=0x7fffffffd7c0, source=0x4aec8d0, force=<value optimized out>) at ThumbnailCache.vala:331
#9  0x000000000042956a in thumbnail_cache_import (photo_id=0x7fffffffd7c0, source=0x4aec8d0, force=1) at ThumbnailCache.vala:146
#10 0x000000000045c850 in library_photo_import (file=<value optimized out>, import_id=<value optimized out>, photo=0x7fffffffd850)
#11 0x00000000004628e0 in batch_import_import_file (self=0x2f30b30, job=0x276bd20, file=0x4cf7f60, copy_to_library=80727648, id=0x4cfdda0 "/home/mnemo/src/mozilla/toolkit/components/places/tests/unit/favicon-scale160x3.jpg") at BatchImport.vala:347
#12 batch_import_import (self=0x2f30b30, job=0x276bd20, file=0x4cf7f60, copy_to_library=80727648, id=0x4cfdda0 "/home/mnemo/src/mozilla/toolkit/components/places/tests/unit/favicon-scale160x3.jpg") at BatchImport.vala:232
#13 0x0000000000462d1e in batch_import_import_dir (self=0x2f30b30, job=0x276bd20, dir=0x4cfce00, copy_to_library=<value optimized out>) at BatchImport.vala:260

(a complete "bt full" gdb log is attached if you're interested)

		Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shotwell_scanning_mozilla_source_tree.log
Type: text/x-log
Size: 33838 bytes
Desc: not available
URL: <https://mail.gnome.org/archives/shotwell-list/attachments/20091216/0e628228/attachment.bin>