crash after f-spot import.
Submitted by an unknown user
Assigned to Lucas Beeler
Link to original bug (#717961)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-09-02 09:55:00 -0700 ----
Original Redmine bug id: 4090
Original URL: http://redmine.yorba.org/issues/4090
Searchable id: yorba-bug-4090
Original author: Seb seb
Original description:
Hi,
I decided to switch to shotwell with the 0.11 release. I have approx 10500 photos in f-spot with 3/4 raw files with tags writtent in the files themselves.
After using the "f-spot import" option, which took approx 12 hours, I was able to use the software. I shut it down and tried to restart it, unsuccessfully.
After displaying a loading progress bar, it crashes at 48% and I get in return :
ERROR:src/sidebar/Branch.c:339:sidebar_branch_graft: assertion failed: (tmp0)
googling this error only gives me only one result, the 4045 : http://redmine.yorba.org/issues/4045
Is there a way to repair it ? I cannot start the shotwell anymore...
Related issues:
- related to shotwell - 4081: F-Spot import creates both top-level and hierarchical tag... (Fixed)
- related to shotwell - 4045: dragging parent under child deletes both, causes assertio... (Fixed)
---- 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
- Priority changed from Normal to Urgent
- Target version changed from 0.11 to 0.11.1
There's kind of two problems here, the problem of the program crashing at import and then now the program not starting. Worrying about the more immediate one, it would help if we knew why Shotwell wasn't starting. Can you follow the instructions here:
http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ#I-found-a-bug-in- Shotwell-How-can-I-report-it
And attach the two files it generates to this ticket? Thanks.
Comment 2
Updated by Jim Nelson about 2 years ago
Lucas thinks this might be related to #4081 (closed) and the other bugs that are giving us trouble with files with both flattened and heirarchical tags during import and reimport.
Comment 3
Updated by Seb seb about 2 years ago
- File shotwell.log added
Not sure if I understand correctly Jim, but in my case shotwell did not crash during the import phase : it was very long but the importation was OK and I was able to use the software as long as I did not shut it down.
Oh and BTW, I'm on Lubuntu 11.04 32bit, using the Natty Yorba PPA.
Here is the shotwell.log file I got following the link you gave me. I admit I don't know why you mention TWO files, here I only have one LOG. I guess maybe I can give you what the terminal said :
bq.
seb@sebpc:~$ SHOTWELL_LOG=1 gdb shotwell 2>&1 | tee shotwell.gdb
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<[http://www.gnu.org/software/gdb/bugs/>](http://www.gnu.org/software/gdb/bugs />)...
Reading symbols from /usr/bin/shotwell...done.
(gdb) run
Starting program: /usr/bin/shotwell
[Thread debugging using libthread_db enabled]
[New Thread 0xafdc3b70 (LWP 3667)]
[New Thread 0xaf3ffb70 (LWP 3668)]
[New Thread 0xaebfeb70 (LWP 3669)]
[New Thread 0xae3fdb70 (LWP 3670)]
**
ERROR:src/sidebar/Branch.c:339:sidebar_branch_graft: assertion failed: (tmp0)
[New Thread 0xad7ffb70 (LWP 3676)]
Program received signal SIGABRT, Aborted.
0x0012e416 in __kernel_vsyscall ()
(gdb) backtrace full
#0 0x0012e416 in __kernel_vsyscall ()
No symbol table info available.
#1 0x024b7e71 in raise () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#2 0x024bb34e in abort () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#3 0x022c03a0 in g_assertion_message (domain=0x0,
file=0x838ccdb "src/sidebar/Branch.c", line=339,
func=0x838d3df "sidebar_branch_graft", message=)
at /build/buildd/glib2.0-2.28.6/./glib/gtestutils.c:1358
lstr = "3390036433762023643376202X355377277,232+02I!213b203320.0232033222"
s = 0x8890620 "360263^02360263^02c/sidebar/Branch.c:339:sidebar_branch_graft: assertion failed: (tmp0)"
#4 0x022c097d in g_assertion_message_expr (domain=0x0,
file=0x838ccdb "src/sidebar/Branch.c", line=339,
func=0x838d3df "sidebar_branch_graft", expr=0x839f8d8 "tmp0")
at /build/buildd/glib2.0-2.28.6/./glib/gtestutils.c:1369
s = 0x88b2130 "assertion failed: (tmp0)"
#5 0x08172e62 in sidebar_branch_graft (self=0x8555c00, parent=0xad8d4f0,
entry=0xad8d518, comparator=0) at src/sidebar/Branch.c:339
tmp0 =
tmp1 =
tmp2 =
tmp3 = 0x0
parent_node =
tmp4 = 0
tmp5 = 0x0
entry_node =
PRETTY_FUNCTION = "sidebar_branch_graft"
#6 0x0818ac8d in tags_branch_on_tags_added_removed (self=0xad7b318,
added_raw=, removed=0x0) at src/tags/Branch.c:1022
tmp14 = 0xad8d4f0
parent_entry = 0xad8d4f0
tmp7 =
tmp13 = 0xad8d810
tmp6 =
tag = 0xad7b318
tmp8 =
parent_tag = 0xad8d810
tmp12 = 0xad8d518
entry = 0xad8d518
tmp5 = 0x8555ca8
_tag_it = 0x8555ca8
tmp0 =
added = 0xace2930
PRETTY_FUNCTION = "tags_branch_on_tags_added_removed"
#7 0x0818ae2e in tags_branch_construct (object_type=143361760)
at src/tags/Branch.c:873
self = 0x8555c00
tmp0 =
tmp1 =
tmp2 = 0x8555c70
tmp3 = 0x8555c70
#8 0x0818aedf in tags_branch_new () at src/tags/Branch.c:882
No locals.
#9 0x08125b34 in library_window_instance_init (self=0xad82060)
at src/library/LibraryWindow.c:5892
tmp0 =
tmp1 =
tmp2 =
tmp3 =
tmp4 =
tmp5 =
tmp6 =
tmp7 = 0x0
tmp8 = 0x0
tmp9 = 0x0
tmp10 = 0x0
tmp11 = 0x0
tmp12 = 0x0
tmp13 = 0x0
tmp14 = 0x0
tmp15 = 0x0
tmp16 = 0x0
tmp17 = 0x0
tmp18 = 0x0
tmp19 = 0x0
tmp20 = 0x0
tmp21 = 0x0
tmp22 = 0x0
tmp23 = 0x0
tmp24 = 0x0
#10 0x021fecc9 in g_type_create_instance (type=145431608)
at /build/buildd/glib2.0-2.28.6/./gobject/gtype.c:1889
node = 0x8ab1c38
instance = 0xad82060
class = 0xa82fe08
i =
total_size = 0
#11 0x021db675 in g_object_constructor (type=145431608,
n_construct_properties=2, construct_params=0x8ed3ef0)
at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c:1615
object =
#12 0x021de674 in g_object_newv (object_type=145431608, n_parameters=0,
parameters=0x0) at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c:1479
cparams = 0x8ed3ef0
oparams = 0x0
nqueue = 0x0
object =
class = 0xa82fe08
unref_class = 0xa82fe08
slist =
n_total_cparams =
n_cparams = 2
n_oparams =
n_cvalues = 2
cvalues = 0x88d5660
clist =
newly_constructed =
i =
PRETTY_FUNCTION = "g_object_newv"
#13 0x021dfa40 in g_object_new (object_type=145431608,
first_property_name=0x0)
at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c:1308
var_args =
PRETTY_FUNCTION = "g_object_new"
#14 0x081cdc6a in page_window_construct (object_type=145431608)
at src/AppWindow.c:1291
self = 0x0
#15 0x081d1016 in app_window_construct (object_type=145431608)
at src/AppWindow.c:1638
self = 0x0
tmp0 =
pixbuf_list =
tmp11 = 0x0
tmp12 =
tmp13 = 0x0
tmp15 = 0x0
tmp16 =
tmp17 = 0x0
inner_error = 0x0
PRETTY_FUNCTION = "app_window_construct"
#16 0x0812f26f in library_window_construct (object_type=145431608,
progress_monitor=0x81cb830 <_aggregate_progress_monitor_monitor_progress_monitor>, progress_monitor_target=0x87b0a80) at src/library/LibraryWindow.c:2137
self = 0x0
tmp0 = 0x0
tmp1 = 0x0
tmp2 = 0x0
tmp3 = 0x0
tmp4 = 0x0
tmp5 =
tmp14 = 0x0
main_window_dnd_targets =
main_window_dnd_targets_length1 =
main_window_dnd_targets_size =
tmp15 = 0x0
tmp16 =
tmp17 = 0x0
tmp18 =
tmp19 = 0x0
tmp20 =
monitor =
tmp21 = 0x0
tmp22 =
tmp23 = 0x0
tmp24 =
tmp25 = 0x0
tmp26 =
#17 0x081305ad in library_window_new (
progress_monitor=0x81cb830 <_aggregate_progress_monitor_monitor_progress_monitor>, progress_monitor_target=0x87b0a80) at src/library/LibraryWindow.c:2243
No locals.
#18 0x081cc069 in library_exec (mounts=0x8461908, mounts_length1=0)
at src/main.c:1038
tmp0 = 0x845f828
shotwell = 0x845f828
tmp1 = 0
tmp2 = 0
tmp5 =
tmp6 =
tmp7 =
tmp8 =
errormsg =
app_version = 0x85119c0 "0.11.0"
schema_version = 142281344
tmp9 = 0x85119c0 "0.11.0"
tmp10 = 14
tmp11 =
result =
progress_dialog =
aggregate_monitor =
monitor =
monitor_target =
monitor_target_destroy_notify =
tmp45 =
tmp46 =
tmp47 = 0xa613080
registry = 0xa613080
tmp48 = 0x0
library_window =
tmp50 = 0
tmp51 = 0x0
tmp52 =
tmp53 =
tmp54 =
tmp64 =
tmp65 = 0x0
tmp66 =
inner_error = 0x0
#19 0x081cd785 in _vala_main (args=0xbffff494, args_length1=1)
at src/main.c:1592
tmp0 =
tmp1 =
tmp2 =
tmp9 =
tmp10 = 5
tmp11 =
tmp12 = 0x0
_tmp12__length1 =
tmp16 = 0x8461908
mounts = 0x8461908
mounts_length1 =
mounts_size =
filename =
tmp25 =
tmp26 =
tmp27 =
tmp28 =
tmp29 = 0x8487520
tmp30 =
tmp31 = 0
tmp32 =
inner_error = 0x0
#20 0x081cda18 in main (argc=1, argv=0xbffff494) at src/main.c:1657
No locals.
(gdb) quit
A debugging session is active.
Inferior 1 [process 3664] will be killed.
Quit anyway? (y or n) y
Is that what you need ?
Comment 4
Updated by Lucas Beeler about 2 years ago
Hi Seb,
It's understandable that this didn't happen until after you quit and restarted Shotwell. The import you did likely created a tag tree structure that Shotwell's sidebar code didn't like. While populating the sidebar dynamically during import might not have triggered an assertion, populating the sidebar in one fell swoop at startup did. I do think this is related to some of the other bugs that Jim mentioned, however, because all of the bugs in question involve the HTag exclusion logic. This is to say, if we know that a tag component (say "dogs") is part of an HTag path (say "/animals/dogs/labradors/" then the corresponding flat tag "dogs" should be excluded from import. The reason we need the exclusion logic is that almost all photo software in existence that supports hierarchical tags (e.g., Adobe Lightroom, DigiKam, Windows Live Photo Gallery) is configured by default to write the hierarchical tag information to the Xmp.lr.hierarchicalSubject field and then to flatten the tags into their components and then write those components into the usual keyword subject metadata fields (e.g., Iptc.Application2.keywords). So we need to exclude these duplicated flat keywords on reimport into Shotwell.
Lucas
Comment 5
Updated by Lucas Beeler about 2 years ago
- Assignee set to Lucas Beeler
Comment 6
Updated by Seb seb about 2 years ago
Thanks Lucas. Your assumption may really be true in my case. I kinda use a lot tags and I remember seing, right after import, in the sidebar same tags in different locations. Words such as "Beach" and "beach" for example, and involving indeed hierarchical tags.
Comment 7
Updated by Lucas Beeler about 2 years ago
Hi Seb,
In a couple of hours, I should be committing a change to the Shotwell git master that will fix a bunch of duplicate tag problems during import from F-Spot. When I do commit that fix, I'll mark this ticket as closed. That said, I would like you to do something for me. Could you send a copy of your Shotwell database file to me at lucas@yorba.org? Your database file is located at ~/.shotwell/data/photo.db. As I said before, I think that your F-Spot import might've mucked with your Shotwell database, so I'd like to see your database file to get a clearer picture of what happened.
After I commit the fix for the F-Spot import tags problem later tonight, I'll post again on this ticket. If you want to begin to use Shotwell then (you said you were moving to Shotwell from F-Spot), you can build and install the current development version of Shotwell from the Yorba git repository by following the instructions here: http://www.yorba.org/shotwell/install<source. Once you've got the current development version installed, you should be able to delete your old Shotwell database (after sending it to me, of course) and run your import from F-Spot again.
Lucas
Comment 8
Updated by Lucas Beeler about 2 years ago
- Status changed from Open to 5
- Resolution set to fixed
Fixed in c59cc117 and 2aca7356
Comment 9
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as bug 4090 at http://redmine.yorba.org/show_bug.cgi?id=4090 Imported an attachment (id=262157)
Unknown Component Using default product and component set in Parameters 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.11.1
Resolution: RESOLVED FIXED