After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 482128 - Hangs on XPM file
Hangs on XPM file
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: general
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-01 11:10 UTC by Sven Arvidsson
Modified: 2007-10-02 17:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
sample xpm file (5.03 KB, image/x-xpixmap)
2007-10-01 11:11 UTC, Sven Arvidsson
  Details
first try to patch it (1.93 KB, patch)
2007-10-01 17:01 UTC, Felix Riemann
none Details | Review

Description Sven Arvidsson 2007-10-01 11:10:31 UTC
eog seems to hang if it's launched with an xpm file as an argument (or by clicking on it) it works fine if the xpm file is viewed as part of an image collection.

I'm attaching a sample xpm file, and a backtrace;

Starting program: /usr/bin/eog Pictures/aisleriot.xpm
[Thread debugging using libthread_db enabled]
[New Thread 0xb6c1d6c0 (LWP 7208)]
[New Thread 0xb69afb90 (LWP 7216)]

Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb6c1d6c0 (LWP 7208)]
0xffffe410 in __kernel_vsyscall ()


Comment 1 Sven Arvidsson 2007-10-01 11:11:05 UTC
Created attachment 96454 [details]
sample xpm file
Comment 2 Felix Riemann 2007-10-01 12:21:29 UTC
Hmm, the XPM-loader apparently doesn't fire the size-prepared signal until you close it.
This let's it skip the point where threadsafe, metadata-less loaders should initiate the window realization (as EOG still thinks it's not threadsafe, which is resolved once the size-prepared signal is emitted).

It then also skips the window realization where non-threadsafe loaders should do it, as the signal has been emitted in the meantime and the loader is now "officially" threadsafe.
Comment 3 Felix Riemann 2007-10-01 17:01:31 UTC
Created attachment 96475 [details] [review]
first try to patch it

So, this is a first try to fix it.
This tries to utilize that EOG now tries to get a GdkPixbufLoader based on the image's mimetype. Those know if the corresponding loader module is threadsafe without having to be fed with data which makes it possible to declare a loader threadsafe earlier in the process.

I'll see if I can optimize a little more as currently it does the threadsafety test twice for non-threadsafe loaders.
Comment 4 Felix Riemann 2007-10-02 17:17:05 UTC
Okay, I just committed an improved version of the patch which only checks once (if successful) to both branches (I think it is "small" enough for stable).


2007-10-02  Felix Riemann  <>

	* src/eog-image.c: (check_loader_threadsafety),
	(eog_image_pre_size_prepared), (eog_image_real_load):
	Try to check the GdkPixbufLoader's threadsafety as early as possible.
	This makes late-emitting loaders (like XPM-loader) work again.
	Fixes bug #482128.


-----

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.