Created attachment 276732 [details]
Shotwell log

Downstream bug https://bugs.launchpad.net/shotwell/+bug/1322661

Weird -- are you sure this is the right stack trace?  I don't see Shotwell's code anywhere on the stack.  It appears to be crashing somewhere inside of GTK+.

I used the instructions in https://wiki.gnome.org/Apps/Shotwell/ReportingABug to run shotwell under gdb and when it crashed that is what I got.  The file does say "Starting program: /usr/bin/shotwell".  It seemed less prone to crashing under gdb and it was several days of use before it failed, I can try and repeat the exercise if it might help.

If you install the package libgtk-3-0-dbg you should be able to get a stack trace with hopefully more useful information.

(In reply to comment #4)
> I used the instructions in https://wiki.gnome.org/Apps/Shotwell/ReportingABug
> to run shotwell under gdb and when it crashed that is what I got.

Colin, did you mean to attach a gdb trace?  There's no file attached.

The gdb trace is linked from my first report and in the table at the bottom of this bug.

I have installed the libgtk dbg package but have not managed to get it to fail again yet.  I suspect it may be a timing or corruption related issue as I cannot find a repeatable way of making it fail.

As the crash is hard to reproduce, you might also want to attach a core file here. You can generate that from inside gdb: http://stackoverflow.com/questions/3789550/saving-core-file-in-gdb

Created attachment 277384 [details]
gdb backtrace full

I have got it to fail again, with the addition symbol data.  Trace and Log attached.  It would not provide a core file, it said "Couldn't get registers: No such process."

It does seem to be some sort of sequence that is necessary to make it fail, I can delete files immediately after startup without triggering the problem, but if I use Shotwell for some time and then delete a single file it may crash immediately.

Created attachment 277385 [details]
Shotwell log

Is the Gtk-CRITICAL error before the crash significant?  I have just made it crash again, but this was some time after doing some deletes.  I was just clicking around the event tree randomly, looking at photos, zooming in and out and so on, then the little square next to one of the events disappeared and it shifted left, as if it were being edited, but it was not in edit mode, and I could not see the photos by clicking on it.  After a bit of fiddling about it crashed with the same trace as before, and again the gtk critical error was there.  I don't know when it appeared though.

First of all, I can't really explain why you are seeing this crash. Second, I'm new to Shotwell development, so take my reasonings below with a grain of salt.

Clearly at the second to bottom stack frame there is some garbage data about the size of the TreeView (which would be the left sidebar):

+ Trace 233654

The crash seems to be related to the sidebar (as you noticed in your latest comment), so I'd think that you shouldn't see crashes if you disable the side bar (View -> Sidebar). Even if that prevents the crash, this is of course not a solution, but it might help in narrowing down the issue.

In any case, The place where the segmentation fault happens is in some tree walking algorithm which by the looks of it does not expect to segmentation fault. It might be that there is a bug in GTK+ too, somewhere.

To move forward in tracking down the bug, it would be best to find a way first for you, Colin, to reliably reproduce it and then for others too. Could you try if what have you expanded in the sidebar makes a difference? Or whether which page (whole library, single event, etc) you have open makes a difference?

The Gtk-CRITICAL assertion message would seem to be related to deleting photos (and possibly something from the sidebar), but I don't immediately see what it exactly means.

About creating a core file:

In principle, running shotwell from the command line as follows:

$ ulimit -c unlimited
$ shotwell

Should give you a file called core inside the same directory. I don't use Ubuntu, but they have a thing called Apport (https://wiki.ubuntu.com/Apport) which might get in the way. In that case, you can try:

$ echo core | sudo tee /proc/sys/kernel/core_pattern
$ ulimit -c unlimited
$ shotwell

The critical error is suspicious:

(shotwell:18480): Gtk-CRITICAL **: gtk_container_remove: assertion 'gtk_widget_get_parent (widget) == GTK_WIDGET (container) || GTK_IS_ASSISTANT (container)' failed

This means some block of code attempted to get the parent of the widget (i.e. the container), and the returned pointer was neither a widget itself of an Assistant.  Often these errors indicate NULL was returned, and since you're in the process of deleting photos, that's suspicious.

The stack trace is deep in the GtkTreeView size allocation code.  I wonder if deleting the photo removed an Event and/or a Tag, which requires updating the GtkTreeView.

But it's difficult to tell from this just what the problem is or what we need to do to fix it.  A repro case would be very useful.

Right, I am getting somewhere.  I have a procedure that repeatedly generates the gtk-critical assertion and a crash.  To reproduce:
Create two sets of nested tags, so for example tag1 containing tag1a and tag1b, and tag2 containing tag2a and tag2b, each with some photos therein.
Expand both sets of tabs in the tree view.
Select one of the inner tags (say tag1a) and double click on one of the photos to view it.
Click on the triangle by the other outer tag (tag2) which collapses it,  but leaves tag1a selected.
Click on tag1a again, even though it is already selected.
The assertion is generated and the tag icon beside tag1a disappears.

Click on the triangle by tag1 again to expand it.
Click on the triangle by tag2 and a segmentation fault occurs.

I am not certain that this is exactly what has caused my crashing when deleting photos but it looks very similar and at least it is a repeatable failure, for me at least.  Hopefully someone else will be able to repeat it.

I can confirm that these instructions lead to a crash for me too, also with a build from the latest git source of Shotwell.

For me, when I click on tag1a after collapsing there are two options:

1. Clicking on the icon does nothing.
2. Clicking on the tag name goes into a sort of "edit mode" (faulty, only the widget type is changed to an Entry, I think, but Shotwell doesn't consider it to be fully in edit mode) and this leads to a crash on clicking the arrow. The icon doesn't disappear for me.

When an item in the Tree is properly in edit mode, the first click on the arrow to collapse doesn't collapse, but instead gets back from edit mode. Only the second click then collapses.

This is great! I think that implementing a fix on the Shotwell side should be easy now (I'd like to do it myself: I don't have time today, but hopefully tomorrow).

Jim (or someone else): do you think there's something here to report as a bug for GTK?

Created attachment 277934 [details] [review]
Patch to fix the issue.

The attached simple fix in the button handling code fixes the issue without adverse side effects as far as I can tell.

While working on this, I noticed that if you right click on a row somewhere other than the text, you get the same context menu, but hitting rename does nothing. Rename only works if you do the right click on top of the text. Is this something that should be fixed (in a separate bug)?

It will be a few days before I can try this, I will need to setup a build environment and I am busy at the moment.  I will get onto it as soon as I can.

Fantastic, this patch solves the problem for me too.

I've ticketed the rename issue at bug #731480.

Pushed to master, commit e09c43

I can confirm that since building with git master I have not seen any crashes whilst deleting photos.