assertion failed in hash_timed_queue_removed while importing photos from F-Spot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Shotwell |
Fix Released
|
Undecided
|
Unassigned | ||
shotwell (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
$ shotwell
**
ERROR:x86_
Aborted
While attempting to import an F-Spot collection (around 158,000 photos) into an existing Shotwell collection (around 48,500 photos), Shotwell terminated with the error message shown above after processing 16,968 F-Spot photos. These photos have remained within Shotwell and are visible in the Last Import list.
The import process ran for around 9 hours before failing, with "import preparation" occupying the first several of these hours; this suggests a polynomial (O(n^c)) or greater import processing time which might be another bug in itself.
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: shotwell 0.9.3-0ubuntu0.1
ProcVersionSign
Uname: Linux 2.6.38-12-generic x86_64
Architecture: amd64
Date: Wed Nov 30 17:00:38 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
ProcEnviron:
LANGUAGE=en_US:en
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: shotwell
UpgradeStatus: No upgrade log present (probably fresh install)
Changed in shotwell (Ubuntu): | |
status: | New → Fix Committed |
importance: | Undecided → Low |
Changed in shotwell: | |
status: | New → Fix Released |
Hi, and thank you for reporting this.
Here are some things you might try that could help:
1. Upgrade your Shotwell package to the latest one available in the repository for Natty Narwhal (which should be 0.10).
2. Try rerunning the scenario with debugging enabled and with a smaller import; if this triggers the crash a second time, it'll provide logging info, and hopefully some insight into what happened immediately before the assertion.
In the meantime, I'll talk to my team lead about possibly relaxing this assertion; what seems to be happening is that, in removed(), it's complaining that an item isn't in the hash map before it sets out to remove it. It may be possible to safely fail silently in that case (to wit: whatever I was supposed to remove is already gone or never got added to begin with, so my work here is done).
As for import speed, and indeed, speed in general with larger libraries, it's very much on our minds; please have a look at http:// redmine. yorba.org/ issues/ 3980 (the numbers you posted above will be added to the bug).