GNOME Bugzilla – Bug 425094
crash when browsing folders with changing contents
Last modified: 2007-08-25 19:41:20 UTC
What were you doing when the application crashed? Browsing catalogs with images while scanning in new images to those catalogs Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 125571072 vsize: 0 resident: 125571072 share: 0 rss: 56893440 rss_rlim: 0 CPU usage: start_time: 1175415775 rtime: 0 utime: 2829 stime: 0 cutime:2650 cstime: 0 timeout: 179 it_real_value: 0 frequency: 222 Backtrace was generated from '/usr/local/bin/gthumb' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1227262288 (LWP 5476)] [New Thread -1279792224 (LWP 5497)] [New Thread -1279263840 (LWP 5496)] [New Thread -1277449312 (LWP 5495)] [New Thread -1260041312 (LWP 5492)] [New Thread -1259512928 (LWP 5490)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 124008
Thread 1 (Thread -1227262288 (LWP 5476))
I am using the meta-ideas branch with some additions in catalog_web_exporter.c which *should* not cause this instability... // Joakim
Here is another one, same situation. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 187101184 vsize: 0 resident: 187101184 share: 0 rss: 97673216 rss_rlim: 0 CPU usage: start_time: 1175418337 rtime: 0 utime: 13376 stime: 0 cutime:12641 cstime: 0 timeout: 735 it_real_value: 0 frequency: 428 Backtrace was generated from '/usr/local/bin/gthumb' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1226905936 (LWP 7001)] [New Thread -1281021024 (LWP 14012)] [New Thread -1281549408 (LWP 14011)] [New Thread -1282077792 (LWP 14010)] [New Thread -1279272032 (LWP 7020)] [New Thread -1278743648 (LWP 7019)] [New Thread -1278215264 (LWP 7018)] [New Thread -1259684960 (LWP 7015)] [New Thread -1259156576 (LWP 7010)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 124048
Thread 1 (Thread -1226905936 (LWP 7001))
And again. I'll try reinstall a pure metadata-ideas versionversion and reboot to see if it happens again. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 80191488 vsize: 0 resident: 80191488 share: 0 rss: 21606400 rss_rlim: 0 CPU usage: start_time: 1175450581 rtime: 0 utime: 157 stime: 0 cutime:143 cstime: 0 timeout: 14 it_real_value: 0 frequency: 6 Backtrace was generated from '/usr/local/bin/gthumb' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1227213136 (LWP 23348)] [New Thread -1279792224 (LWP 23365)] [New Thread -1279263840 (LWP 23364)] [New Thread -1277400160 (LWP 23363)] [New Thread -1259992160 (LWP 23360)] [New Thread -1259463776 (LWP 23358)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 124131
Thread 1 (Thread -1227213136 (LWP 23348))
Hi Joakim, Could you explain exactly how to reproduce this crash? - Mike
Well, I'd hoped that someone would get something useful out from the backtraces. My impression is that it happens when you browse catalogs where images are simultaneously created, form instance by a scanner or by someone moving images to and/or from the catalog. I'll see if I can stress it to happen on purpose, otherwise it happens a couple of hours apart when I scan images. // Joakim
Joakim, I don't use catalogs much, so forgive me if I seem slow: Why are you adding images to a catalog before the scanning of that image is complete? Is this a scenario that is likely to occur again? I just want to understand the usage pattern a bit better, before trying to fix it... - Mike
Mike, with catalog I mean file system catalog (directory), not a gthumb catalog. Think of it as a workflow. The scanner is scanning negative strips of six images at a time. It takes about 10 minutes per strip so while scanning the next strip the user (me at least) wants to rotate and fix the previously scanned images a bit like adding the correct date information and maybe a suitable comment like "Summer 1987, Paris". Since this takes place in the same catalog as the scanner software (vuescan) creates new images and probably temp files gthumb needs to be more robust compared to a static catalog with no changes applied. Of course the workaround is to do one thing at a time but also you want to check that the scanner is doing what you expect along the way too. I guess it could have to do with that other bug fixed, if the temp files for instance does not have a matching mime type. I will let you know if it crashes with that fix in place too. // Joakim
Joakim, Thanks, that clarifies things a lot. We are talking about folders, not catalogs. I suspect that vuescan creates a temporary file, which gThumb starts to read, and then vuescan renames the file, causing gThumb to crash. (Do you see vuescan creating temporary files?) The backtrace in comment 2 crashes at gth-fullscreen.c:132 which is g_object_unref (priv->image); Maybe the file monitor code has already unref'd priv->image? The initial backtrace and the one in comment 3 crash at gth-file-view-list.c:1144, which is different. I'm not very good at debugging this type of code... perhaps Manuel can take a look. - Mike
Joakim, This might have been fixed in svn trunk rev 1610, by a patch for bug 432084. Let me know if the problem still exists or not. - Mike
ok, I will install the TRUNK and try it out shortly. // Joakim
*** Bug 418628 has been marked as a duplicate of this bug. ***
*** Bug 445126 has been marked as a duplicate of this bug. ***
Probably fixed. Please re-open if it occurs in gthumb 2.10.6 or higher. - Mike
*** Bug 448701 has been marked as a duplicate of this bug. ***
*** Bug 470253 has been marked as a duplicate of this bug. ***