GNOME Bugzilla – Bug 78542
Thumbnails for jpegs render slowly, copying file hourglass icon crashes Nautilus
Last modified: 2004-12-22 21:47:04 UTC
This may be similar to 48213. If a CDROM folder with many jpeg images is opened under nautilus, the images icons become an hourglass. Thumbnails for a directory with many medium-sized jpegs can take a very long time to render. If I try to copy one of these images to another drive while the hourglass icon is displayed, Nautilus crashes with the following traceback: detected a multithreaded program t@1 (l@1) terminated by signal ABRT (Abort) 0xfd99c670: __lwp_kill+0x0008: bgeu,a __lwp_kill+0x1c Current function is g_logv 507 abort (); (.../forte/6u2_FCS/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where current thread: t@1 [1] __lwp_kill(0x0, 0x6, 0x0, 0xfd9b8000, 0x81010100, 0xff00), at 0xfd99c670 [2] raise(0x6, 0x0, 0xffbfe708, 0xff051894, 0xff051894, 0xffbfeb9c), at 0xfd94b8ac [3] abort(0xfeb746c8, 0x6, 0xffbfe7d7, 0x0, 0xfda0b034, 0x0), at 0xfd935508 =>[4] g_logv(log_domain = 0xfeb746c8 "libgnomevfs", log_level = G_LOG_LEVEL_ERROR, format = 0xfeb746d4 "file %s: line %d: assertion failed: (%s)", args1 = 0xffbfec90), line 507 in "gmessages.c" [5] g_log(log_domain = 0xfeb746c8 "libgnomevfs", log_level = G_LOG_LEVEL_ERROR, format = 0xfeb746d4 "file %s: line %d: assertion failed: (%s)", ...), line 526 in "gmessages.c" [6] dispatch_sync_job_callback(data = 0xfce7bb10), line 435 in "gnome-vfs-job.c" [7] g_idle_dispatch(source = 0x7f5cd8, callback = 0xfeb3e400 = &`libgnomevfs-2.so.0.0.0`gnome-vfs-job.c`dispatch_sync_job_callback(gpointer data), user_data = 0xfce7bb10), line 3129 in "gmain.c" [8] g_main_dispatch(context = 0x1a43a0), line 1619 in "gmain.c" "/tmp/nautcrash.tmp" 21 lines, 1612 characters
I can't duplicate this (Linux, cvs build of April 12). I don't get the hourglass, I just get the standard jpg icon with no thumbnail (this, I guess, is a separate bug), and I don't get the crash when I try to copy to my hard drive.
Probably solaris specific then. Marking critical/high and cc'ing Dave.
This still occurs in the 21-April CVS head. It doesn't crash unless the hourglass appears (indicating that thumbnail rendering is in progress.) It's easiest to duplicate on a cdrom with more than 100 images in a directory so that the hourglasses will remain long enough for you to drag one to the desktop.
Damon: welcome on board the nautilus team ;)
I can't reproduce on Linux, using files on the hard drive. I'll try it on Solaris tomorrow, using a CD if I can create one. Though looking at the code it uses fork() when creating thumbnails, which sounds a bit dodgy to me. Will gnome-vfs handle that OK? Surely both processes will have the same job map so it is likely to get a bit confused. I'd rather it only forked when it execs "convert", and possibly uses a new thread for the other parts.
I have long wanted to rewrite it to use threads. The current code is just plain strange. Using threads should give better performance too.
Is this another duplicate of bug 76338, Damon, Alex?
No. It doesn't look like a dup of bug 76338
Dave managed to reproduce this on his Sun Ultra 2 (dual processor). It doesn't happen every time, though. I'm going to rewrite the thumbnail code to use a thread for most of the work, and only fork if it needs to exec 'convert'. I'm not sure that is the cause of the problem, but there is a good chance it is and it needs fixing anyway. I don't think gnome-vfs is set up to work across fork(). It needs to use pthread_atfork() and probably clear the job table in the child. I've added bug #81076 about this.
Created attachment 8643 [details] [review] Patch to use a thread instead of forking, except when we need to run convert
Created attachment 8669 [details] [review] Updated patch - fixes race condition, handles convert hanging.
I finally managed to reproduce it on Solaris as well. I've committed the patch to cvs, with some minor changes alex suggested. Now we wait to see if that fixed the bug... (I'd say its about a 50% chance).
I've tried about 20 times and can't reproduce it. But I couldn't reproduce it easily before, so it may still be there. I'll close, but please reopen if anyone still sees it.
I can't reproduce it anymore here either, thanks.