Shotwell crashes within a few seconds of F-Spot import

[Matt Hegarty]

Binary package hint: shotwell

I started Shotwell
Select "import from default f-spot library (~/.config/f-spot/photos.db)"
It goes through "preparing photos for import"
then starts importing (I see the pictures flashing on screen)
it crashes within 2-3 seconds everytime

This is on ubuntu 10.10
Shotwell 0.7.2
F-spot 0.8.0

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: shotwell 0.7.2-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
NonfreeKernelModules: fglrx
Architecture: i386
Date: Sun Nov 14 21:05:47 2010
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: shotwell

[Adam Dingle (adam-yorba)]

We've had a couple of import-related crashes. One is related to a memory leak; bug #662216 now points to http://trac.yorba.org/ticket/2566, which is about that memory leak.

But the crash described here occurs in just a few seconds, so it's not that. We'd be interested to see a backtrace for this crash. You could follow the backtrace instructions in the Shotwell FAQ at http://trac.yorba.org/wiki/Shotwell/FAQ . If you get a backtrace, please post it here and we can perhaps unmark this as a duplicate.

[Matt Hegarty (mrhegarty)]

Debug logs attached as requested

[Matt Hegarty (mrhegarty)]

I noticed that the crash happened after around 10 seconds. I was watching the memory usage and the crash happened when memory usage was around 31MB (as reported by "System Monitor")

[Matt Hegarty (mrhegarty)]

Each time it seems to import 16-19 pictures before crashing, these pictures are retained each time - so it seems to successfully import these then crashes. It also seems to manage to pick up where it left off. These pictures will be of similar size (~ 4 -12 MB). Mem usage seems to get to about 30-50MB (260MB virtual) (monitoring in System Monitor)

[Adam Dingle (adam-yorba)]

Thanks for the debug logs. I've ticketed this upstream at http://trac.yorba.org/ticket/2842 . This is a different bug than the memory leak crash described in #662216. I recommend removing duplicate status (I have no power to do so myself, I believe).

[Omer Akram (om26er)]

> I recommend removing duplicate status (I have no power to do so myself, I believe).

you can. click on the duplicate button and remove the duplicate bug number and enter. only bug importance and a few special statuses are set by ubuntu-bugcontrol since you are upstream developer you can join ubuntu-bugcontrol (three is special love for upstreams ;))

[Jim Nelson (yorba-jim)]

Looking at the log files, I'm seeing a couple of things that are suspicious. First:

L 2436 2010-11-16 20:21:21 [WRN] AlienDatabaseImportJob.vala:32: Could not get file metadata for img_0141.jpg: /media/FAT/img_0141.jpg: Failed to open the data source: No such file or directory (errno = 2)
L 2436 2010-11-16 20:21:21 [WRN] AlienDatabaseImportJob.vala:59: Could not get modification time for img_0141.jpg: Error stating file '/media/FAT/img_0141.jpg': No such file or directory

It appears you're trying to import off an attached drive, but the files can't be read, not even the modification time. What kind of drive is it?

Second:

L 2436 2010-11-16 20:21:46 [WRN] PhotoMetadata.vala:542: Unable to read date/time Exif.Photo.DateTimeOriginal from source cnv00036.jpg: : : : : is not EXIF format date/time
L 2436 2010-11-16 20:21:46 [CRT] photo_metadata_read_from_file: assertion `G_IS_FILE (file)' failed
L 2436 2010-11-16 20:21:46 [CRT] gboolean gexiv2_metadata_has_tag(GExiv2Metadata*, const gchar*): assertion `self->priv->image.get() != NULL' failed

This makes it look like the files contain bogus metadata. Why this is triggering other problems is odd to me.

Could you send me the filec cnv00036.jpg and cnv00037.jpg (if it exists?) It looks to me like these are also possibly related to the problem. My email is <email address hidden>. Thanks!

[Adam Dingle (adam-yorba)]

Matt,

it's hard for us to make much progress on this bug since we're completely unable to reproduce it. A few questions:

1. Can you still reproduce this?

2. From the log file you sent, it's clear that Shotwell is having trouble accessing numerous files. The log shows that as soon as Shotwell starts up, it is unable to read some of the thumbnail files from the ~/.shotwell/thumbs directory. Jim mentioned that you said some of your files are on a FAT filesystem. Is your .shotwell directory on that filesystem? Have you deleted any files from the .shotwell directory?

3. The log file shows that Shotwell is also unable to read various photo files from the /media/FAT directory. Can you access these files normally, for example using Nautilus?

[Matt Hegarty (mrhegarty)]

Hi Adam

I haven't retried because I just "manually" imported my photos into
Shotwell, and don't want to screw anything up with an F-Spot import!

Whatever I did also has caused problems with F-Spot - hence why I
migrated to Shotwell. (F-Spot crashes as soon as I click one of the
problem pictures).

What I think happened is this:

I had some photos which were digitised from film onto CD a few years
back by a high street chemist. I originally uploaded these pictures to
Windows.

Recently I tried to import them into F-Spot (from Ubuntu) - although I
can't remember exactly, I'm sure I moved them from my Windows partition
to my Linux partition, and then imported them to F-Spot. This caused
F-Spot to crash and I haven't been able to recover from it. In F-Spot,
the thumbnails don't appear, though if you click on the space where the
thumbnail should be, then F-Spot crashes. I filed an F-Spot bug:
(https://bugzilla.gnome.org/show_bug.cgi?id=634856)

I switched to Shotwell, then tried the "import from F-Spot function" -
which caused the issue.

The pictures are on my ext4 home partition, eg:

-r-xr-xr-x 1 matthew matthew 462248 2010-11-11 19:18 cnv00036.jpg

My .shotwell dir is also under /home/matthew on my Linux partition.
I can view the files normally via Nautilus, and I can view files in
/media/windows also.

I have not directly deleted from .shotwell - although I will have
deleted files via SW itself.

FWIW this is no longer an issue for me as I manually imported my photos
and retagged - though I'm happy to do more digging for you if you want
to try to get the bug fixed. I think if you were to import the photo I
sent to Jim into F-Spot, to see if that crashed, then you might be able
to reproduce it in Shotwell.

Cheers
Matt

On 20/12/10 21:12, Adam Dingle wrote:
> Matt,
>
> it's hard for us to make much progress on this bug since we're
> completely unable to reproduce it. A few questions:
>
> 1. Can you still reproduce this?
>
> 2. From the log file you sent, it's clear that Shotwell is having
> trouble accessing numerous files. The log shows that as soon as
> Shotwell starts up, it is unable to read some of the thumbnail files
> from the ~/.shotwell/thumbs directory. Jim mentioned that you said some
> of your files are on a FAT filesystem. Is your .shotwell directory on
> that filesystem? Have you deleted any files from the .shotwell
> directory?
>
> 3. The log file shows that Shotwell is also unable to read various photo
> files from the /media/FAT directory. Can you access these files
> normally, for example using Nautilus?
>

[Omer Akram (om26er)]

Closing this bug, since its not an issue for you and the upstream bug is closed.