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 447063 - eog hangs when opening SVG files that include external images
eog hangs when opening SVG files that include external images
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: image viewer
unspecified
Other Linux
: Normal blocker
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on: 449409
Blocks:
 
 
Reported: 2007-06-13 09:35 UTC by Michael Krause
Modified: 2007-09-05 10:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Michael Krause 2007-06-13 09:35:39 UTC
- Download the following SVG and the TIF file that is included by the SVG:

  http://www.om.tu-harburg.de/eogbug/test.svg
  http://www.om.tu-harburg.de/eogbug/n_.tif

- Put the files in the same directory, cd into that directory, and run
  'eog test.svg'.

- Nothing happens, eog just hangs.

This is not so bad, I don't usually use eog from the shell. BUT: The main problem is that nautilus hangs when I enter the directory containing the above-mentioned SVG. I think that's because nautilus calls eog to get the preview image, but eog never returns. This is very annoying, because I have to restart nautilus.
Comment 1 Felix Riemann 2007-06-13 09:52:11 UTC
Confirming.
There appears to be a deadlock somewhere:

  • #11 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #12 _gdk_pixbuf_lock
    at gdk-pixbuf-io.c line 108
  • #13 gdk_pixbuf_loader_load_module
    at gdk-pixbuf-loader.c line 380
  • #14 IA__gdk_pixbuf_loader_write
    at gdk-pixbuf-loader.c line 418
  • #15 rsvg_pixbuf_new_from_href
    at rsvg-image.c line 406
  • #16 rsvg_node_image_set_atts
    at rsvg-image.c line 555
  • #17 rsvg_node_set_atts
    at rsvg-base.c line 1615
  • #18 rsvg_standard_element_start
    at rsvg-base.c line 262
  • #19 rsvg_start_element
    at rsvg-base.c line 686

Comment 2 Felix Riemann 2007-06-21 18:12:47 UTC
Okay, we seem to be hitting two problems here.

The first one comes from gdk-pixbuf. Here the SVG-loader sets a lock which the TIFF-loader needs to set as well and thus deadlocks as it is called from inside the SVG-loader. (See bug 449409 for more information).

The second one is that you need to start eog from the directory where your image file is located as it wont find the embedded image otherwise.
Comment 3 Lucas Rocha 2007-09-04 20:57:34 UTC
I refactored Felix' patch (Thanks Felix!) on bug #449409 and it really seems to work around this non-threadsafe loader problem. Fixed in trunk.

2007-09-04  Lucas Rocha  <lucasr@gnome.org>

        * src/eog-image-private.h: added threadsafe_format private attribute.
        * src/eog-image.c (+eog_image_pre_size_prepared,
        eog_image_size_prepared, eog_image_real_load): detect non-threadsafe
        loaders and disable any possible asyncronous task that could bring
        deadlocks to image loading process. Fixes bug #449409 (Felix Riemann).
Comment 4 Felix Riemann 2007-09-05 10:08:34 UTC
Lucas, are you sure this is fixed? It is still (expectedly) hanging here.

The first problem (loading an SVG while realizing the window) is fixed, but the next that happens is that librsvg uses GdkPixbufLoader itself to load the embedded/referenced TIFF file.
This produces the same deadlock as before (to thread-unsafe loaders at the same time), but there is probably nothing here we can do against it (as it is out of EOG's scope).
Comment 5 Lucas Rocha 2007-09-05 10:25:30 UTC
This patch is a good-enough work around for the most critical problem of basic image loading with non-threadsafe loaders. 

The remaining (major) bug should be kept in separate report for gdk-pixbuf (See bug #473862).