[devlibs-gtk3] Inkscape crashes with ImageMagick related commands

Bug #1252719 reported by jazzynico on 2013-11-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape Devlibs

Bug Description

Inkscape crashes when using the raster extensions or importing a BMP file (ImageMagick fallback).
Reproduced with Inkscape trunk revision 12823 and devlibs-gtk3 r27 (imagemagick-

The crash seems to occur in extension/internal/bitmap/imagemagick.cpp, line 131 (ImageMagickDocCache::readImage, image->read(blob);)

jazzynico (jazzynico) on 2013-11-19
description: updated
jazzynico (jazzynico) wrote :

Apparently the crashes have different causes.

1. Opening a file from a long path triggers the following console error:
terminate called after throwing an instance of 'Magick::ErrorBlob'
  what(): Magick: UnableToOpenBlob `C:\Documents and Settings\All Users\Documents\Mes images\├ëchan
tillons d'images\Hiver.jpg': No such file or directory @ error/blob.c/OpenBlob/2641
Opening the same file from a shorter path (c:\Hiver.jpg) works.

2. Running the Oil Paint, Median and Reduce Noise raster extensions triggers a pop-up (nothing in the console) with the following messages.
--- With Oil Paint:
(inkscape.exe:1340): glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: Magick: MemoryAllocationFailed `'@ error/paint.c/OilPaintImage/619
--- With Median and Reduce Noise:
(inkscape.exe:1340): glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: Magick: MemoryAllocationFailed `'@ error/statistic.c/StatisticImageChannel/2783

3. Some other raster extensions (Add Noise, Dither), Inkscape crashes with no pop-up or console message.

All the other raster extensions work as expected (at least with the default values and the ones I have tested).

jazzynico (jazzynico) wrote :

Crash 1 occurs in extension/internal/image-resolution.cpp (ImageResolution::readmagick).
The same code doesn't crash with the official devlibs.

jazzynico (jazzynico) wrote :

Same issues reproduced when using imagemagick-6.8.7 (last IM version) instead of imagemagick-6.8.2 (devlibs-gtk3 version).

I've notice some type errors in the raster extensions (we use an "int" where IM expects a double, or a float instead of a size_t...), but I'm not sure it's directly related to our crashes.

jazzynico (jazzynico) wrote :

Some details on crash 1:
* It's not due to the length of the path, but on the special character in "Échantillons d'images".
* The path seems to be wrong indeed, and that's the reason why the code goes to the ImageMagick fallback (it should be correctly opened by the jfif function). It's not specific to the devlibs, but affects the Inkscape trunk.
* It crashes in the IM fallback because the try/catch block doesn't catch the image.read exception (with the official devlibs, the exception is caught and ignored, and thus the imported image has a default resolution).

Thus we have two bugs for crash 1:
1.a. Wrong path when there are special characters (Inkscape trunk). Doesn't lead to a crash itself, but prevent the import code from using the image resolution.
1.b. Exception not caught in the IM fallback (devlibs-gtk3), that causes the crash.

jazzynico (jazzynico) wrote :

That bug really reminds me of bug #173116 (Gtk::PixbufError exception not caught in Windows)...

jazzynico (jazzynico) wrote :

... BTW, it seems that bug #173116 is back with the original devlibs.

Johan Engelen (johanengelen) wrote :

did you build with "--shared-libgcc" ? I believe that was one of the pieces important to fix bug #173116

jazzynico (jazzynico) wrote :

Also occurs when copy-pasting from an external application.

> did you build with "--shared-libgcc"

I thought the Opensuse libs were compiled with SJLJ, not DW2, and thus that the flag is not required. But since we see exceptions not caught, I guess you are right.
Unfortunately, it defeats the purpose of getting rid of manually build dependencies...

jazzynico (jazzynico) wrote :

@Johan - I misunderstood your comment. libgcc needs to be shared when compiling Inkscape, not it's dependencies...
Thus adding -shared-libgcc in the build.xml file (link flags) solves issues 1 (partially) and 2, and bug #173116. Change committed revision 34. I've also added some exception handling code trunk revision 12836 to help debugging IM code.

But unfortunately Inkscape still crashes with:
1bis. Copy-pasting from an external application (again due to the ImageMagick resolution fallback).
3. Add Noise and Dither extensions.

Johan Engelen (johanengelen) wrote :

@Jazz: i also didn't know how to apply --shared-libgcc :-)

Johan Engelen (johanengelen) wrote :

Jazz, something just hit me: you download the binaries of a bunch of libs right? Those are built with mingw (not TDM), so they will have DW2 exception handling (right?). Then you compile some others using TDM -> SJLJ exception handling. If we are mixing exception handling styles... I'm surprised the whole thing links, actually :-) I'll see if I can build with standard mingw.

Johan Engelen (johanengelen) wrote :

It links with standard MinGW after disabling aspell, but then Inkscape crashes on boot because it cannot find __gxx_personality_v0 in libstdc++-6.dll.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers