[norepro] Crashes on startup with assertion failure in source_holding_tank_internal_notify_altered
Submitted by an unknown user
Assigned to cli..@..ba.org
Link to original bug (#718065)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-14 19:35:00 -0700 ----
Original Redmine bug id: 3981
Original URL: http://redmine.yorba.org/issues/3981
Searchable id: yorba-bug-3981
Original author: Jonathan Rascher
Original description:
I've been using Shotwell successfully for a few months now, but today it appears that something broke. I was browsing through some pictures (and possibly changing titles or tags, I can't remember) when Shotwell suddenly marked one of the pictures as missing. I've had problems with spurious "missing" photos before, and they always resolved themselves with a restart, so I closed and reopened Shotwell. Unfortunately, now Shotwell dies with an assertion failure every time it's run. (The main window is displayed for a second or two, and it seems to be populated with my photos, but then the program aborts.) The following is printed to stderr when this happens:
%{=font-family:courier new,courier,monospace;}** (process:10540): DEBUG: GConfEngine.vala:191: Converting GConf settings to gsettings...
- Message: GConfEngine.vala:201: Error 6 running gsettings-data-convert: stdout="" stderr="
GLib-GIO-ERROR **: Settings schema 'org.yorba.shotwell.sharing.facebook' does not contain a key named 'default-size'
aborting...
"
- (process:10540): DEBUG: GConfEngine.vala:205: GConf to gsettings conversion completed
libusb couldn't open USB device /dev/bus/usb/002/003: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/003/005: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/004/003: Permission denied.
L 10652 2011-08-14 22:10:36 [MSG] main.vala:410: Shotwell Photo Manager 0.10.90+trunk
L 10652 2011-08-14 22:10:36 [MSG] main.vala:73: Verifying database ...
L 10652 2011-08-14 22:10:36 [MSG] VideoSupport.vala:329: interpreter state cookie not found; assuming all video thumbnails are out of date
...skipping...
libusb requires write access to USB device nodes.
**
ERROR:src/core/SourceHoldingTank.c:663:source_holding_tank_internal_notify_alt ered: assertion failed: (tmp0)
Aborted%
The original failure occured with Shotwell 0.10.1. Per this mailing list post I tried it with the latest git version as well, but the same thing happens. I've attached a backtrace and log, as well as my photo.db. Let me know if there's anything else I can do to help debug this.
Related issues:
- related to shotwell - 3263: Shotwell crashes on startup (Invalid)
- related to shotwell - 4056: Ensure all publishing keys are converted from GConf to GS... (Fixed)
- related to shotwell - 4073: GLib-GIO-ERROR causing system start-up delay with latest ... (Fixed)
- duplicated by shotwell - 6084: Crash/hang on opening. SourceHoldingTank.vala:167:source_... (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
History
Comment 1
Updated by Jim Nelson about 2 years ago
- Category set to 4
- Assignee set to Clinton Rogers
- Priority changed from Normal to Urgent
- Target version set to 0.11.1
Jonathan, thanks for sending all this information to us. This got overlooked in our return from the Desktop Summit to Berlin. We'll take a look and see if we can figure out what's going on.
This may be related to #3263 (closed), which was closed due to lack of information from the reporter.
Comment 2
Updated by Clinton Rogers about 2 years ago
Hi Jonathan,
I've been tasked with researching this issue, and, if you don't mind, I'd like to get a bit more detail on the events leading up to it. May I know:
...if the affected database contained images that lived on media that weren't mounted or readable at the time it became corrupted? (the libusb warnings)
...if any of the images in the database were modified outside of shotwell?
This seems very similar to something reported via the mailing list back in June (http://lists.yorba.org/pipermail/shotwell/2011-June/002430.html), but we never succeeded in reproducing it here.
Incidentally, thank you for reporting this and for all the added info; you may have provided the clues we need to squash this one once and for all.
Comment 3
Updated by Jonathan Rascher about 2 years ago
No problem. Sorry about the delay on my end as well; I'm finishing up a summer internship right now and so my schedule's been pretty hectic.
Clinton, to answer your questions:
- No, all the stuff in my library is stored on a local hard disk. The partition they live on is always mounted (it's my home partition), and it doesn't appear that any of the imag files have been corrupted.
- Yes, many of the images in my library have been tweaked in GIMP through Shotwell's "open in external editor" feature.
Comment 4
Updated by Jim Nelson about 2 years ago
Jonathan, I have an unrelated question. In your log sample above, there are these lines:
%{=font-family: courier new,courier,monospace;}** (process:10540): DEBUG: GConfEngine.vala:191: Converting GConf settings to gsettings...
- Message: GConfEngine.vala:201: Error 6 running gsettings-data-convert: stdout="" stderr="
GLib-GIO-ERROR **: Settings schema 'org.yorba.shotwell.sharing.facebook' does not contain a key named 'default-size'
aborting...
"
- (process:10540): DEBUG: GConfEngine.vala:205: GConf to gsettings conversion completed%
We're trying to figure out why this error is occurring (#4056 (closed)). First, do you see this message every time you run Shotwell? Second, did you install Shotwell or are you running it from the build directory (that is, you downloaded the tarball and built it yourself)?
If you could answer on #4056 (closed), it would be greatly appreciated.
Comment 5
Updated by Jim Nelson about 2 years ago
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
)
Comment 6
Updated by Jim Nelson about 2 years ago
- Target version changed from 0.11.1 to 0.12
We've been unable to reproduce this. I'm not inclined to close this because we have had it reported before and have no reason to believe any recent code change has fixed it. However, we won't be able to make any movement on this in time for 0.11.1. Postponing to 0.12.
Comment 7
Updated by Adam Dingle almost 2 years ago
- Subject changed from Crashes on startup with assertion failure in source_holding_tank_internal_notify_altered to [norepro] Crashes on startup with assertion failure in source_holding_tank_internal_notify_altered
- Description updated (diff)
- Priority changed from Urgent to High
Comment 8
Updated by Clinton Rogers almost 2 years ago
This bug seems to have claimed another victim; please see https://answers.launchpad.net/ubuntu/+source/shotwell/+question/181737. I've contacted this user for more information and his photo.db; hopefully, we'll be able to get a sample of a 'crashy' database under lab conditions...
Comment 9
Updated by Adam Dingle over 1 year ago
-
Target version deleted (
<strike>
_0.12_</strike>
)
Comment 10
Updated by Alexander Amelkin about 1 year ago
- File photo.db.gz added
- Target version set to 0.11.5
Guys, seeing this bug a year old is very frustrating.
It started happening to me all of a sudden today.
It started with the stock version of Shotwell for my Ubuntu Natty.
I upgraded from your PPA to version 0.11.6, but the bug still exists.
Here is the output I get to the terminal if I run shotwell manually:
spirit@myrth:~$ shotwell
** (process:12662): DEBUG: GConfEngine.vala:191: Converting GConf settings to gsettings...
** Message: GConfEngine.vala:201: Error 6 running gsettings-data-convert: stdout="" stderr="
GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.background' is not installed
aborting...
"
** (process:12662): DEBUG: GConfEngine.vala:205: GConf to gsettings conversion completed
(shotwell:12662): GLib-GIO-CRITICAL **: g_file_hash: assertion `G_IS_FILE (file)' failed
(shotwell:12662): GLib-GIO-CRITICAL **: g_file_hash: assertion `G_IS_FILE (file)' failed
**
ERROR:src/core/SourceHoldingTank.c:663:source_holding_tank_internal_notify_altered: assertion failed: (_tmp0_)
Аварийный останов
spirit@myrth:~$
I don't see 0.11.5 among versions here in redmine, so I set the target to 0.11.5.
My photo.db is attached.
Comment 11
Updated by Jim Nelson 12 months ago
- Target version changed from 0.11.5 to 0.14.0
We use the target version to indicate the version of Shotwell we want to add the fix to (or was fixed in, if the ticket is closed). We'll take another look at this for the upcoming 0.14 release, as we've had a lot of trouble reproducing this.
Comment 12
Updated by Jim Nelson 11 months ago
- Category set to library-mode
- Assignee set to Jim Nelson
- Priority changed from High to Urgent
Comment 13
Updated by Jim Nelson 9 months ago
-
Assignee deleted (
<strike>
_Jim Nelson_</strike>
)
Comment 14
Updated by Jim Nelson 9 months ago
- File 3981.diff added
- Assignee set to Clinton Rogers
Let's compile, test, and commit the attached diff.
Comment 15
Updated by Clinton Rogers 9 months ago
- Status changed from Open to Review
- % Done changed from 0 to 70
Comment 16
Updated by Lucas Beeler 9 months ago
Review: approve. Commit!
Comment 17
Updated by Clinton Rogers 9 months ago
- Status changed from Review to 5
- % Done changed from 70 to 100
- Resolution set to fixed
Note: the code for this was actually written by Jim.
Comment 18
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC ---
This bug was previously known as bug 3981 at http://redmine.yorba.org/show_bug.cgi?id=3981 Imported an attachment (id=262177) Imported an attachment (id=262178) Imported an attachment (id=262179) Imported an attachment (id=262180) Imported an attachment (id=262181)
Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.14.0
Resolution: RESOLVED FIXED