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 499514 - Various segfaults with librsvg in mutlithreaded enivronments.
Various segfaults with librsvg in mutlithreaded enivronments.
Status: RESOLVED DUPLICATE of bug 377539
Product: pango
Classification: Platform
Component: general
unspecified
Other All
: Normal critical
: ---
Assigned To: pango-maint
pango-maint
Depends on: pango-threadsafe
Blocks:
 
 
Reported: 2007-11-25 11:00 UTC by Wolfgang Glas
Modified: 2012-08-22 02:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
The test case, which test multi-threading in rsvg. (5.68 KB, text/x-csrc)
2007-11-25 11:03 UTC, Wolfgang Glas
Details
Modified testcase with g_thread_init and prerendering. (5.72 KB, text/plain)
2007-11-25 20:21 UTC, Wolfgang Glas
Details

Description Wolfgang Glas 2007-11-25 11:00:16 UTC
Steps to reproduce:

1. Start the accompanying C Program with renders an SVG file parallelly in multiple threads.
2. Depending on the number of threads an your hardware you receive different crashes.
3. The attached debug session is on Intel Core Duo, x86_64, ubuntu gusty, 1,2,3,10,20 threads.

Stack trace:
/home/wglas/CC > gdb ./rsvg-thread-testGNU gdb 6.6-debian
Copyright (C) 2006 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 "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb)  r  /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 1
Starting program: /home/wglas/CC/rsvg-thread-test /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 1
[Thread debugging using libthread_db enabled]
[New Thread 46980317031552 (LWP 14538)]
[New Thread 1082132816 (LWP 14541)]
Starting thread 0.
Finished thread 0.
[Thread 1082132816 (LWP 14541) exited]

Program exited with code 01.
(gdb)  r  /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 2
Starting program: /home/wglas/CC/rsvg-thread-test /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 2
[Thread debugging using libthread_db enabled]
[New Thread 47628347620480 (LWP 14546)]
[New Thread 1082132816 (LWP 14547)]
Starting thread 0.
[New Thread 1090525520 (LWP 14548)]
Starting thread 1.
Finished thread 1.
[Thread 1090525520 (LWP 14548) exited]
Finished thread 0.
[Thread 1082132816 (LWP 14547) exited]

Program exited with code 01.
(gdb)  r  /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 3
Starting program: /home/wglas/CC/rsvg-thread-test /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 3
[Thread debugging using libthread_db enabled]
[New Thread 47509588118656 (LWP 14549)]
[New Thread 1082132816 (LWP 14553)]
Starting thread 0.
[New Thread 1090525520 (LWP 14554)]
Starting thread 1.
[New Thread 1098918224 (LWP 14555)]
Starting thread 2.

Program received signal SIGSEGV, Segmentation fault.

Thread 1082132816 (LWP 14553)

  • #0 g_hash_table_insert
    from /usr/lib/libglib-2.0.so.0
  • #1 ??
    from /usr/lib/librsvg-2.so.2
  • #2 ??
    from /usr/lib/librsvg-2.so.2
  • #3 xmlParseStartTag
    from /usr/lib/libxml2.so.2
  • #4 xmlParseChunk
    from /usr/lib/libxml2.so.2
  • #5 ??
    from /usr/lib/librsvg-2.so.2
  • #6 render_thread_run
    at rsvg-thread-test.c line 133
  • #7 start_thread
    from /lib/libpthread.so.0
  • #8 clone
    from /lib/libc.so.6
  • #9 ??

Thread 1082132816 (LWP 14563)

  • #0 g_hash_table_insert
    from /usr/lib/libglib-2.0.so.0
  • #1 ??
    from /usr/lib/librsvg-2.so.2
  • #2 ??
    from /usr/lib/librsvg-2.so.2
  • #3 xmlParseStartTag
    from /usr/lib/libxml2.so.2
  • #4 xmlParseChunk
    from /usr/lib/libxml2.so.2
  • #5 ??
    from /usr/lib/librsvg-2.so.2
  • #6 render_thread_run
    at rsvg-thread-test.c line 133
  • #7 start_thread
    from /lib/libpthread.so.0
  • #8 clone
    from /lib/libc.so.6
  • #9 ??

Thread 1157667152 (LWP 14586)

  • #0 g_slice_alloc
    from /usr/lib/libglib-2.0.so.0
  • #1 ??
    from /usr/lib/libglib-2.0.so.0
  • #2 g_hash_table_insert
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
    from /usr/lib/librsvg-2.so.2
  • #4 ??
    from /usr/lib/librsvg-2.so.2
  • #5 xmlParseStartTag
    from /usr/lib/libxml2.so.2
  • #6 xmlParseChunk
    from /usr/lib/libxml2.so.2
  • #7 ??
    from /usr/lib/librsvg-2.so.2
  • #8 render_thread_run
    at rsvg-thread-test.c line 133
  • #9 start_thread
    from /lib/libpthread.so.0
  • #10 clone
    from /lib/libc.so.6
  • #11 ??
The program is running.  Exit anyway? (y or n) y


Other information:
Comment 1 Wolfgang Glas 2007-11-25 11:03:23 UTC
Created attachment 99610 [details]
The test case, which test multi-threading in rsvg.

Compile instructions are contained in the C file.

Run it using:

rsvg_render_test input.png <output-base-name> <nthreads>

Renders input.png in <nthreads> threads.
The output files are named output-base-name-%d.png
Comment 2 Emmanuel Pacaud 2007-11-25 14:23:11 UTC
I'm not sure about the thread support in librsvg itself, but at least thread support at the glib level should be initiliazed by a call to gthread_init.

Also, it seems pango is not initiliazed. I don't know how to do it properly, but a call to gkt_init seems to fix the issue.
Comment 3 Dominic Lachowicz 2007-11-25 15:25:04 UTC
Please add a call to g_thread_init(NULL) before rsvg_init() and try this program again.

librsvg itself doesn't have any code that I"m aware of that shouldn't be MT safe, provided that you don't try to use the same RsvgHandle in different threads.
Comment 4 Wolfgang Glas 2007-11-25 20:21:14 UTC
Created attachment 99633 [details]
Modified testcase with g_thread_init and prerendering.

This modified testcase uses rsvg_endle_new_from_file, which is a small simplification.

Additionally, it call g_thread_init(NULL) at startup. This fixes the program mostyl, but with a let's say 10% propability my program crashes with 5-7 thread like in the following example:

**********
  ./rsvg-thread-test2 /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 7
Starting thread 0.
Starting thread 1.
Starting thread 2.
Starting thread 3.
Starting thread 4.
Starting thread 5.
Starting thread 6.

(process:25071): GLib-GObject-WARNING **: IA__g_object_new_valist: object class `GdkPixbuf' has no property named `colorspace'
Thread 0: Error saving pixel buffer: Fatal error in PNG image file: Image width or height is zero in IHDR.
Finished thread 2.
Finished thread 1.
Finished thread 3.
Thread 0 failed.
Finished thread 4.
Finished thread 6.
Finished thread 5.
**********

Another scenarios ocurring at a comparable propability is:

**********
 ./rsvg-thread-test2 /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 7
Starting thread 0.
Starting thread 3.
Starting thread 2.
Starting thread 1.
Starting thread 6.
Starting thread 5.
Starting thread 4.
Thread 2: Error fetching pixel buffer from svg handle.

(process:24902): GdkPixbuf-CRITICAL **: _gdk_pixbuf_load_module_unlocked: assertion `image_module->module == NULL' failed

(process:24902): GdkPixbuf-CRITICAL **: gdk_pixbuf_savev: assertion `error == NULL || *error != NULL' failed
Segmentation fault (core dumped)
*******

Both problem disappear, if I render a single image before I enter multithreading, which may be established by the newly introduced '-prerender' cmdline option as in the following example:

./rsvg-thread-test2 -prerender /usr/share/icons/Mist/scalable/places/folder-new.svg tmp 7

The whole testcase indicates, that there is some non-thread-safe initialization code inside gdk-pixbuf. However, I did not find a gdk_pixbuf_init() function or a similar functionality to undertake the gdk-pixbuf initialization beforehand.

Calling gtk_init() is not an option for me,because my target application shall be a rendering server, which should run w/o a GUI.

  Thanks for your help so far,

    Wolfgang
Comment 5 Dominic Lachowicz 2007-11-25 20:41:54 UTC
Thanks. This looks like a thread-safety issue inside of GdkPixbuf. Reassigning.
Comment 6 Matthias Clasen 2011-12-16 23:26:31 UTC
librsvg is using pango for text, which is not threadsafe
Comment 7 Dominic Lachowicz 2011-12-17 00:00:21 UTC
Moving to pango then. We're only as threadsafe as our dependencies.
Comment 8 Matthias Clasen 2012-08-22 02:38:47 UTC

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