---- 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](http://lists.yorba.org/pipermail/shotwell/2011-June/002430.html) 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

####

#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, which was closed due to lack of information from
the reporter.


####

#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.

####

#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.

####

#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).  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, it would be greatly appreciated.

####

#5

Updated by Jim Nelson about 2 years ago

  * **Assignee** deleted (<strike>_Clinton Rogers_</strike>)


####

#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.


####

#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_

####

#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...

####

#9

Updated by Adam Dingle over 1 year ago

  * **Target version** deleted (<strike>_0.12_</strike>)

####

#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.

####

#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.

####

#12

Updated by Jim Nelson 11 months ago

  * **Category** set to _library-mode_
  * **Assignee** set to _Jim Nelson_
  * **Priority** changed from _High_ to _Urgent_

####

#13

Updated by Jim Nelson 9 months ago

  * **Assignee** deleted (<strike>_Jim Nelson_</strike>)

####

#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.

####

#15

Updated by Clinton Rogers 9 months ago

  * **Status** changed from _Open_ to _Review_
  * **% Done** changed from _0_ to _70_

####

#16

Updated by Lucas Beeler 9 months ago

Review: approve. Commit!

####

#17

Updated by Clinton Rogers 9 months ago

  * **Status** changed from _Review_ to _5_
  * **% Done** changed from _70_ to _100_
  * **Resolution** set to _fixed_

7428233fef4bfdcf288c1849121eab8350ec795a

Note: the code for this was actually written by Jim.

####

#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.