Is this bug reproducible on every time you run EOG? Did you try to open different images on different locations? This indeed seems to be a very specifid race condition in threaded code.

I can reproduce it quite easily. Not exactly every second or third run but surely every day. I've just put a check to bounce out of the code if priv is NULL so we don't attempt to dereference it. I guess if we're sure it should be filled in in proper operation, then maybe we should lock the critical section when we set/reset the priv member and the spin on the mutex before we try to dereference the priv structure.

What i can't understand is why, as you can see from above when i start the eog command with *one* file, it stat's my home dir for all possible files and starts 22+ jobs ? I'm requesting to display 1 image !! Also why is this file

  1 /home/mitch/.registry (-1/-1)

assumed to be a image as part of the 22 candidate image files it finds ?? Or am i reading the verbose output wrong ?

Hi Mitch, these are the threads to load thumbnails of the images from the same directory. This is a known performance bug and will be fixed soon. 

About the ".registry" being considered as an image, this is probably the cause of this bug. EOG is trying to load a thumbnail from a non-image file. What is the mime-type of this .registry? I still can't reproduce this bug with EOG 2.13.92.

Created attachment 60472 [details]
My .registry

Hi Lucas, how do i tell what eog thinks is the *mime type* of my .registry file. the file(1) command thinks it's a PCX image !! though 'cat -v' clearly shows it's a registry file...


laptop ~% file .registry
.registry: PCX ver. 2.5 image data
laptop ~% strings .registry
HKLM
HKCU
HKCU\Software\LinuxLoader\div3
HKCU\Software\LinuxLoader\div3\BitRate
HKCU\Software\LinuxLoader\div3\KeyFrames
HKCU\Software\LinuxLoader\div3\Crispness
HKCU\SOFTWARE\Microsoft\Scrunch\CPU Clock Speed
HKCU\SOFTWARE\Microsoft\Scrunch\Video\Resolution
HKCU\SOFTWARE\Microsoft\Scrunch\Video\BitRate
HKCU\SOFTWARE\Microsoft\Scrunch\Post Process Mode

Hi Lucas, whatever changes you made in .92 of eog now made it worse. Looks we're stuck on a mutex/condvar now. If i eog an image it hangs (no window comes up ever). If i gdb the process and Ctrl-C it and show the stack here is where i am...

home ~% gdb eog
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r x.pnm
Starting program: /usr/bin/eog x.pnm
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 26927)]
[New Thread 32769 (LWP 26931)]
[New Thread 16386 (LWP 26932)]

Program received signal SIGINT, Interrupt.

+ Trace 66690

I take the last comment 6 back. The 'hang' problem happens even with .91. It seems to loop forever when loading a relatively large pnm file. Try opening this file

http://hasbox.com/x.pnm.gz

with eog (gunzip it first). Imagemagick's 'display' and 'gimp' both load it instantaneously.

I think i figured this out Lucas. This *is* a race condition, but not in your thread code. Essentially files are being removed from under eog whilst it is loading thumbnails. I put some more debugging in job_thumb_finished() to print out the status, and also in eog_collection_item_load() to print the job and the file it is attempting to load and this is what i get:

% gdb eog
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r ~/b1.png
Starting program: /usr/src/sources/gnome/eog-2.14.0/shell/eog ~/b1.png
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 27287)]
[New Thread 32769 (LWP 27290)]
[New Thread 16386 (LWP 27291)]
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
No profile, not correcting
start job job=0x828e500, file=/home/mitch/.face
[New Thread 32771 (LWP 27292)]
start job job=0x828e4d0, file=/home/mitch/.registry
start job job=0x828e560, file=/home/mitch/NATURE-AFlower_1024x768.png
start job job=0x828e6b0, file=/home/mitch/SunRay170.jpg
start job job=0x828e650, file=/home/mitch/b1.png
start job job=0x828e5d0, file=/home/mitch/bill.png
start job job=0x828e4a0, file=/home/mitch/blank.xpm
start job job=0x828c760, file=/home/mitch/half.xpm
start job job=0x8289ad0, file=/home/mitch/header_gradient_top.gif
start job job=0x828e610, file=/home/mitch/img1.jpg
start job job=0x828e4c0, file=/home/mitch/l.jpg
start job job=0x828c7c0, file=/home/mitch/license.gif
start job job=0x828e550, file=/home/mitch/linux_logo2_vsmall.gif
start job job=0x8290910, file=/home/mitch/mydoc.gif
start job job=0x8290950, file=/home/mitch/mydoc.xpm
start job job=0x8290990, file=/home/mitch/p1.pnm
start job job=0x82909d0, file=/home/mitch/sfx4100.png
start job job=0x8290a30, file=/home/mitch/skype.jpg
start job job=0x8290a70, file=/home/mitch/sr.jpg
start job job=0x8290ab0, file=/home/mitch/sr.svg
start job job=0x8290b10, file=/home/mitch/test.jpg
start job job=0x8290b50, file=/home/mitch/test2.jpg
start job job=0x8290b90, file=/home/mitch/test3.jpg
start job job=0x8290bd0, file=/home/mitch/tick_green.gif
start job job=0x8290c30, file=/home/mitch/x.xpm
success job=0x828e500 status=1
success job=0x828e560 status=1
success job=0x828e6b0 status=1
success job=0x828e650 status=1
fail job=0x828e4d0 status=0
success job=0x828e4a0 status=1
success job=0x828c760 status=1
success job=0x8289ad0 status=1
success job=0x828e610 status=1
success job=0x828e4c0 status=1
success job=0x828e5d0 status=1
success job=0x828e550 status=1
success job=0x8290910 status=1
success job=0x8290950 status=1
success job=0x8290990 status=1
success job=0x82909d0 status=1
success job=0x8290a30 status=1
success job=0x828c7c0 status=1
success job=0x8290a70 status=1
success job=0x8290b10 status=1
success job=0x8290ab0 status=1
success job=0x8290b50 status=1
success job=0x8290b90 status=1
success job=0x8290bd0 status=1
success job=0x8290c30 status=1
start job job=0x8270510, file=/home/mitch/.fonts.cache-1.TMP-nv0Wlt

(eog:27291): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: MTime or mime type not available
start job job=0x82d2bd0, file=/home/mitch/.fonts.cache-1.LCK
start job job=0x826bb50, file=/home/mitch/.fonts.cache-1.NEW
start job job=0x8273cb0, file=/home/mitch/.fonts.cache-1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 27292)]
job_thumb_create (job=0x82d2bd0, data=0x82575c8, error=0x826fef0) at eog-collection-item.c:311
311             image = priv->image;
(gdb)


No matter how may times i run it, i always note that the jobid it crashes in in job_thumb_create() is ALWAYS the jobid (0x82d2bd0) of one of the TEMPORARY files that gets created to rebuild the font cache (in this case /home/mitch/.fonts.cache-1.LCK). Note after eog crashes/finishes, the temporary files no longer exist !

So essentially the crash is since the file it is trying to generate a thumbnail gets removed under it's feet !!

Futhermore i did a printf in eog_collection_item_destroy() under 'if (priv) {'
statement and reran. 


success job=0x8290a50 status=1
start job job=0x82703b0, file=/home/mitch/.fonts.cache-1.TMP-s0CZ4R
DESTROY /home/mitch/.fonts.cache-1.TMP-s0CZ4R
start job job=0x826bb40, file=/home/mitch/.fonts.cache-1.LCK
DESTROY /home/mitch/.fonts.cache-1.LCK
start job job=0x8274d70, file=/home/mitch/.fonts.cache-1.NEW
DESTROY /home/mitch/.fonts.cache-1.NEW
start job job=0x8292570, file=/home/mitch/.fonts.cache-1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 27627)]
job_thumb_create (job=0x82703b0, data=0x80ebb98, error=0x82a0548) at eog-collection-item.c:312
312             image = priv->image;
(gdb)


Surprise, surprise ! my DESTROY statement is being printed, and that block does 'g_free (priv)' for the for the 3 temporary font cache files whilst we subsequently try to dereference it in job_thumb_create().

So. In effect i'm verifying the need to retest priv vefore dereferencing in job_thumb_create().  I've add this check

static void
job_thumb_create (EogJob *job, gpointer data, GError **error)
{
        EogCollectionItemPrivate *priv;
        EogImage *image;
        GdkPixbuf *pixbuf;
        GnomeVFSURI *uri;

        priv = EOG_COLLECTION_ITEM (data)->priv;

+       if (!priv)
+               return;

        image = priv->image;


This works perfectly 100% of the time now !!!

Please verify and apply to your tree.

This seems to be same bug as bug #336050 that is fixed now. Closing as duplicate. Feel free to reopen the bug if the problem persists someway.

*** This bug has been marked as a duplicate of 336050 ***