GNOME Bugzilla – Bug 622161
EOG + "Date in statusbar plugin" hangs with specific PNG pictures
Last modified: 2019-02-22 03:16:03 UTC
Created attachment 164112 [details] PNG picture that triggers the bug Using Ubuntu 10.04 AMD64 and i386 (also occurs from the LiveCD) : Short form : opening some PNG pictures with transparency (as the one provided here) with eog, with the "date in the status bar" plugin frequently hangs eog. Without this plugin : it works as expected. Long form : The steps are : - boot from the CD or an already installed system (64 or 32 bits) - mount the device where the .PNG file attached above is stored - open it in eog - preferences -> plugins -> tick "date in statusbar" - close it - reopen the png then, with the very same picture : in about 33% or more of the cases : no window is displayed in about 33% of the cases : eog displays a grey picture in about 33% of the cases or less : it is displayed properly I just close / reopen it several times in a row and randomly get one of those behaviours... Interestingly, if I launch in parallel a very CPU heavy task (i.e. VLC with HD DVB-T channels), the rates above differ significantly. It almost works properly 9 times out of 10... So, depending on the machine, tasks, and so on, one may not be able to reproduce it... This issue already existed in Karmic. It can be reproduced every time here (with the provided PNG picture, and some others -- it never happened, here, with regular jpg photographs). Cheers, thanks for reading this ! This bug was already added to the ubuntu bug tracker here : https://bugs.launchpad.net/ubuntu/+source/eog/+bug/571868
Please also note, the exact version of eog used is : 2.30.0-0ubuntu1
Wow, that's a good example image. Seems to trigger easily. Not sure if there's a quick workaround as the statusbar-date plugin has some known timing problems with image loading.
As this bug is very annoying, and hardly anyone will have the idea that it is connected to this plugin, I suggest removing the plugin until it is fixed. Because not having this plugin is still better than frustrated users.
I actually know what's causing it, although the workaround (a fix would require huge changes) I'm playing with is deadlocking after a while. The image is actually loaded. It's just the main window that is not shown as a signal isn't emitted due to said timing problems. Another workaround (besides disabling the plugin) is also to disable automatic orientation. Depends on what you need more. As we'll need to look at our plugins anyway for GNOME 3.0 one can think about disabling it until we have this sorted out.
I have not thought of this much yet, but somehow I think that by improving the extension points in the core we can rewrite this plugin to be less intrusive. When I find some time I can look at it.. and I wouldn't mind disabling it in master, but that's not gonna make much difference for users until 3.0.
(In reply to comment #5) > I have not thought of this much yet, but somehow I think that by improving the > extension points in the core we can rewrite this plugin to be less intrusive. > When I find some time I can look at it.. and I wouldn't mind disabling it in > master, but that's not gonna make much difference for users until 3.0. The problem is not specific to plugins (one could make it happen with built-in code) but is more or less caused by the current job system. The plugin is calling eog_image_load directly (which one should never ever do) without going through the job system as it could delay other jobs otherwise since the job system can only handle one job at a time. This can make it clash with the actual image loading like in this case, though. I'd like to modernize the whole job handling a bit (like moving jobs into the modules they belong and making them able to wait for other jobs) but it has to wait until I have enough time again and is also in very early planning.
Thanks for your replies, Felix and Claudio. Well, this issue still occurs in eog 2.32.0. Sorry if my post is not that useful :-)
*** Bug 633709 has been marked as a duplicate of this bug. ***
Created attachment 173804 [details] [review] quick workaround I seem to have found a quite simple workaround that could do for now. This workaround simply makes sure only the image loading job clears the autorotate flag. That way the signal to show the window will be sent as soon as the loader noticed there is no exif data present. It's of course not a real solution (a plugin the does image data loading circumvents this) but it worksaround the symptoms for most cases. Please give this a test if you can. I'll also try testing this more thoroughly.
Pushed the workaround for now since the real fix is less likely to appear soonish. Couldn't spot any problems from using the workaround. commit e43fa8ff82c6aedd8f6373a0a5a1a5677f32cd83 Author: Felix Riemann <> Date: Sat Nov 13 14:08:44 2010 +0100 Workaround concurrency issue with statusbar-date plugin Make sure that only an image loading job does autorotation. A metadata loading job has no use for this. Works around lost signals when the statusbar-date plugin is activated. Works around bug 622161. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
*** Bug 634945 has been marked as a duplicate of this bug. ***