GNOME Bugzilla – Bug 390314
crash in F-Spot Photo Manager: Trying to import a direc...
Last modified: 2008-07-16 22:06:04 UTC
What were you doing when the application crashed? Trying to import a directory of images. Since the import file browser did not show my home directory or my Desktop directory I manually entered my home directory, getting this crash. Distribution: Gentoo Base System version 1.12.6 Gnome Release: 2.16.2 2006-11-20 (Gentoo) BugBuddy Version: 2.16.0 Memory status: size: 216633344 vsize: 216633344 resident: 56045568 share: 18780160 rss: 56045568 rss_rlim: -1 CPU usage: start_time: 1167304523 rtime: 875 utime: 833 stime: 42 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/f-spot' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47160069567488 (LWP 16564)] [New Thread 1083406672 (LWP 16569)] [New Thread 1080977744 (LWP 16568)] [New Thread 1078876496 (LWP 16567)] [New Thread 1075988816 (LWP 16566)] [New Thread 1073822032 (LWP 16565)] 0x00002ae44ed8692f in waitpid () from /lib/libpthread.so.0
+ Trace 97507
Thread 1 (Thread 47160069567488 (LWP 16564))
Thanks for taking the time to report this bug. Unfortunately there isn't much we can do with the current stacktrace. Can you reproduce the error after you executed f-spot from a console? The produced stacktrace should give us more information.
When starting f-spot from the shell I still get a crash that is filtered through bug buddy, but I did get the following assertion: Gtk-ERROR **: file gtkfilechooserdefault.c: line 7772 (gtk_file_chooser_default_should_respond): assertion failed: (path != NULL) aborting... In addition the real problem seems to occur earlier, because my file chooser doesn't show me the Desktop and Home directory items that are there normally. The same file chooser in Evolution does show these items and works as expected.
Some more information that might be helpful. When I reported the bug I was still using the 2.8.2 bindings for GTK+ and GNOME. I am currently in the process of updating them, and I found that updating the gnome-sharp bindings to 2.16.0 did give me the Home and Desktop directory entries back, but no files appear in the right-hand area and f-spot seems to have gone in an endless loop. Trying this a second time actually did get me the files. However, subsequent attempts return me to the empty file browser without Home and Desktop entries, and I'm back where I started. So in the end my conclusion is that this is not related to the version of the bindings. Most likely candidate seems to be either an initialization issue or a race conditions. If there are suggestions on how to debug this further I'd be happy to have another look.
Two more data points: The endless loop I mentioned in my previous comment isn't actually an endless loop. Instead it seems to be a problem with event handling. When I cover the window and then uncover it the files in the currently selected directory suddenly appear. By doing this repeatedly I can navigate around and actually import the files. Note that the import dialog (where the to be imported files are previewed and tags can be selected) also suffers from the same issue. After looking around in src/CompatFileChooser.cs I decided to change the #if false on line 233 to #if true. Now I don't have the additional drives anymore that f-spot seems to populate the file chooser with, but I can navigate around again without issues. That solves my problems since I don't care about the extra drives in the menu. Now if only it was so easy to import and tag and comment on all my old photos... :-)
Hi hans, Do you really have a '#if false' on line 233 in src/CompatFileChooser.cs ? And secondly, f-spot doesn't say anything on the console at all ??? in that case, it's more than probably an mono issue :( Anyway, with an updated system (*-sharp, mono and gnome) it should be better...
Actually the '#if false' line is on line 151 of src/CompatFileChooser.cs. I have now updated mono from version 1.1.13.8.1 to 1.2.2.1, reverted my change to src/CompatFileChooser.cs, and recompiled f-spot. Things seem to work again as expected. So I agree that this is most likely an issue with mono. Perhaps f-spot should require a sufficiently new version to avoid bugs like these?
Bad news, I'm seeing this bug again with f-spot compiled with mono 1.2.2.1. It happened today after importing a number of directories, one at a time. Perhaps the problem is related to the number of times the import file chooser is shown or used?
what version of gtk do you have?
I've been using gtk+ 2.10.6 until Jan 19th, then switched to 2.10.7 and back again to 2.10.6 on Jan 20th. Since Jan 26th I'm using 2.10.9. I haven't seen the problem yet since installing 2.10.9, but I have also not had a need to import several times in a row, so I can't tell if 2.10.9 fixes the bug.
Is this problem still occurring, and if so which versions are you using now?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!