Crash on startup while reading ICC profile

[Łukasz Stelmach]

Trunk inkscape (rev. 9930) crashes when reading ICC profiles for my monitor from ~/.local/share/color/icc/devices/display, 0.48 from Gentoo portage does not. Offending example attached.

[su_v (suv-lp)]

Can you get a backtrace of when Inkscape crashes?

Possibly or likely a duplicate of
Bug #623640 “inkscape 0.48 crashes on startup in colorprofile_get_system_profile_handle()”:
<https://bugs.launchpad.net/inkscape/+bug/623640>

Known workaround for bug #623640:
<https://bugs.launchpad.net/inkscape/+bug/623640/comments/17>
or edit '~/.config/inkscape/preferences.xml' as described in
<https://bugs.launchpad.net/inkscape/+bug/608229/comments/9>

[su_v (suv-lp)]

> 0.48 from Gentoo portage does not

Do you have a link to a site listing any patches (to the official Inkscape 0.48.0 tar ball) that are used to build the Inkscape packages provided by/for Gentoo?

[su_v (suv-lp)]

Crash not reproduced with Inkscape 0.48+devel r9926 on OS X 10.5.8 when placing a copy of the attached ICC profile into '~/.local/share/devices/display': the profile gets loaded without error messages, no crash with whatever setting is used for display adjustment in 'Inkscape preferences > Color management > Display Adjustment' (the ColorSync profile is listed among the choices for the display profile).

Also no crash with Inkscape 0.48.0; both versions tested with current and default preferences.

Dependency: lcms @1.19

[su_v (suv-lp)]

correcting typo:
- placing a copy of the attached ICC profile into '~/.local/share/devices/display'
+ placing a copy of the attached ICC profile into '~/.local/share/color/icc/devices/display'

[Łukasz Stelmach (steelman)]

The Gentoo way is:

* ebuild: ftp://ftp.heanet.ie/pub/gentoo-portage/media-gfx/inkscape/inkscape-0.48.0.ebuild
* patch: ftp://ftp.heanet.ie/pub/gentoo-portage/media-gfx/inkscape/files/inkscape-0.48.0-spell.patch
* configure: ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --without-perl --enable-poppler-cairo --with-xft --without-gnome-vfs --without-inkjar --enable-lcms --enable-nls --with-aspell --with-gtkspell

Configuration:

        Source code location: .
        Destination path prefix: /usr
        Compiler: g++
        CPPFLAGS: -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2
        CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -Wno-strict-aliasing -fopenmp
        CFLAGS: -Wno-pointer-sign -g -O2
        LDFLAGS: -Wl,-z,relro

        Use Xft font database: yes
        Use gnome-vfs: no
        Use openoffice files: no
        Use relocation support: no
        Internal Python: skipped
        Internal Perl: no
        Enable LittleCms: yes
        Enable DBUS: no
        Enable Poppler-Cairo: yes
        ImageMagick Magick++: yes
        Libwpg: yes
        Doing Local Install: no

When I compile the current source this way it crashes too. The stack looks as follows

#0 0x0000000000000000 in ?? ()
#1 0x00007ffff1ce5c4f in cmsReadICCTextEx (hProfile=0x4c1a4f0, sig=<value optimized out>,
    Name=0x7ffff1f07ea0 "", size_max=512) at cmsio1.c:1693
#2 0x00007ffff1ce6196 in cmsTakeProductDesc (hProfile=0x4c1a4f0) at cmsio1.c:2217
#3 0x00000000008dabb5 in ProfileInfo (this=0x7fffffffd120, prof=0x4c1a4f0, path=...) at color-profile.cpp:582
#4 0x00000000008dc302 in findThings () at color-profile.cpp:773
#5 0x00000000008dc89f in colorprofile_get_proof_profile_handle () at color-profile.cpp:876
#6 0x00000000008dce74 in Inkscape::colorprofile_get_display_per (id=<value optimized out>)
    at color-profile.cpp:1138
#7 0x0000000000592407 in sp_canvas_paint_single_buffer (setup=<value optimized out>, this_rect=...)
    at display/sp-canvas.cpp:1671
#8 sp_canvas_paint_rect_internal (setup=<value optimized out>, this_rect=...) at display/sp-canvas.cpp:1825
#9 0x00000000005921cd in sp_canvas_paint_rect_internal (setup=<value optimized out>, this_rect=...)
    at display/sp-canvas.cpp:1879
#10 0x0000000000592c66 in sp_canvas_paint_rect (canvas=0x20c25c0) at display/sp-canvas.cpp:1941
#11 paint (canvas=0x20c25c0) at display/sp-canvas.cpp:2093
#12 do_update (canvas=0x20c25c0) at display/sp-canvas.cpp:2130
#13 0x0000000000592e52 in idle_handler (data=<value optimized out>) at display/sp-canvas.cpp:2152
#14 0x00007fffecfc7247 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0x00007fffecfca6c5 in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00007fffecfcabdb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#17 0x00007ffff5ca2bcc in gtk_main ...

[Łukasz Stelmach (steelman)]

This looks even weirder. When I run the current inkscape with LD_PRELOAD=/usr/lib/liblcms.so.1 it's OK but when the same library is loaded automatically inkscape crashes. I really don't know what actually is the issue?

[Łukasz Stelmach (steelman)]

BTW. Inkscape crashes regardless of any frobs referenced in comment #2.

[Niko Kiirala (kiirala)]

I'm experiencing the same problem and comment #7 led me to right tracks.

For some reason, Inkscape ends up having both lcms1 (liblcms.so.1) and lcms2 (liblcms2.so.2) as dynamic dependencies. Both of those libraries provide function cmsOpenProfileFromFile so it depends on load order, which one Inkscape ends up using for loading icc files. The crashing call, cmsTakeProductDesc, exists only in lcms1. By Murphy's law it happens that icc files are loaded with lcms2 function and then processed with lcms1 function...

Don't know yet why this happens or how it could be fixed. LD_PRELOAD can be used as a workaround.

[Niko Kiirala (kiirala)]

OK, it seems that lcms2 is pulled in by Magick++. I'll include bzr merge directive (a patch) that'll allow for disabling Magick++ when compiling Inkscape. Still not quite a proper solution, but better than LD_PRELOAD. Another possibility would be to build Magick++ without cms support.

[ScislaC (scislac)]

To the people who could reproduce this before, does this issue still exist with 0.48.3.1 or trunk?

[su_v (suv-lp)]

Later reports about conflicts triggered by having both lcms and lcms2 as dynamic dependencies:
Bug #1024344 “Color management in trunk broken on OS X after upgrading libffi to 3.0.11” (OS X)
Bug #1125620 “Crashes on trying to open document properties or preferences” (Windows)