Inkscape crashes when opening a large PNG-file

[vigri]

Dear Maintainers,

I would like to report a bug where a large PNG file can crash Inkscape.

Affected Inkscape versions: 0.45 and 0.91
OS: Debian 8.1 x64
Memory: 24 GiB

Steps to reproduce the crash:
1. save the attached PNG image to a folder
2. start inkscape
3. click on 'file' -> 'open'
4. select the PNG file (important: deselect 'preview' to avoid another bug which I reported too)
5. inkscape crashes

I've been able to get additional information with GDB. Please see the attached txt file.

Some additional information which could be important:

--> (gdb) frame 0
#0 0x00007ffff6180667 in gdk_pixbuf_add_alpha (pixbuf=0x4588640, substitute_color=0, r=0 '\000', g=0 '\000', b=0 '\000') at gdk-pixbuf-util.c:112
112 in gdk-pixbuf-util.c
(gdb) info locals
dest = 0x7ffe2bd7c871 <error: Cannot access memory at address 0x7ffe2bd7c871>
tr = <optimized out>
tb = <optimized out>
src = 0x7fffb9a61a59 ""
tg = <optimized out>
new_pixbuf = 0x4588760
x = 0
y = 19885
src_pixels = 0x7fff59a50010 ""
ret_pixels = 0x7ffeabd65010 ""
__func__ = "gdk_pixbuf_add_alpha"

--> Problematic line: tr = *dest++ = *src++;

--> When I try to open a 50k x 50k grayscale PNG the crash happens at row 10738 (instead of row 19855)

Best regards
vigri

[jazzynico (jazzynico)]

Reproduced on Windows XP (32bit), Inkscape trunk revision 14285.

[jazzynico (jazzynico)]

Crash reproduced with the native Windows open/import dialog.

Not reproduced with the GTK dialog. Inkscape doesn't crash but show the following console errors:
----
(inkscape.exe:3416): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler:
domain: gdk-pixbuf-error-quark
code : 1
what : Failed to load image 'D:\SVG\27000_27000_1437947845.png': Insufficient memory to load PNG file

[jazzynico (jazzynico)]

Correction: also crashes with the GTK dialog, but less consistently.

[vigri (vigri-bugreport)]

@jazzynico (jazzynico)

Please ensure to have enough memory. My machine have had 24 GiB.

>Crash reproduced with the native Windows open/import dialog.

Please be sure to deactivate the preview-checkbox.
Letting preview activated leads to another problem (and crash): https://bugs.launchpad.net/inkscape/+bug/1483058

[jazzynico (jazzynico)]

ImageMagick's identify result attached (took quite long to process).

[su_v (suv-lp)]

Based on the information provided by the reporter in bug #1484149, this is an upstream bug in gdk-pixbuf (i.e. not an Inkscape bug).

A related bug report to upstream gdk-pixbuf is not known - bug reports for gdk-pixbuf are tracked in GNOME's bugzilla:
https://bugzilla.gnome.org/page.cgi?id=browse.html&product=gdk-pixbuf

Proposing to close as 'Invalid' for project 'Inkscape'.

[su_v (suv-lp)]

Upstream bug report:
* 753569 – Unhandled integer-overflow leads to segmentation fault
  https://bugzilla.gnome.org/show_bug.cgi?id=753569

[su_v (suv-lp)]

Upstream fix available in latest gdk-pixbuf release (2.31.7)
Related upstream commit:
https://git.gnome.org/browse/gdk-pixbuf/commit/?id=ca3c56421c075e729750cf80c3438b283232cce8

@jazzynico - is there a need to add bug tasks for inkscape-devlibs and inkscape-devlibs64, and to track it as 'Triaged' for project Inkscape until Windows builds of Inskcape ship with a new enough version of gdk-pixbuf which includes this fix?

With regard to Inkscape packages for OS X: I don't think we would have to keep this report open specifically for those. They already use the unstable 2.31.x series of upstream gdk-pixbuf releases (0.91 has 2.31.2, most recent devel snapshot builds (0.91+devel) have 2.31.6, the next one to be uploaded will have 2.31.7), and any future stable release package (be it for 0.91.1, or 0.92) will include the latest available version at the time (unstable or stable, whatever is newer).

(The test case based on which this report was filed is AFAIU a handcrafted PNG file - I do not know how many such files are encountered by Inkscape users in daily usage).

[jazzynico (jazzynico)]

@~suv - Well, I never know what to do with that kind of reports. I'd keep it open until the fixed dependencies are available on the major operation systems, just in case someone else creates another similar report.
As for the devlibs, I'm not even sure which ones are used to create the official packages. I'm still using the official win32 ones for my local tests (they really need to be updated...) and I feel the devlib64 are pretty unstable.