GNOME Bugzilla – Bug 593576
PDF Import filter: crashes when importing large image PDF or specifying high resolution
Last modified: 2018-05-24 12:40:11 UTC
I have several single-page PDF files containing scans of building plans. I loaded the smaller ones (e.g., 14400 pixels by 10889, RGB, 18.7 MB on disk) specifying 600 DPI, and they loaded up fine. However, all the larger ones (e.g., 21600 by 14433 pixels, RGB, 37.3 MB on disk) imported at 600, or even 500 DPI cause the PDF importer plug-in to crash. Lowering the DPI to 200 or 100, it imports fine, but then I'm not getting the full resolution of the image. I also tried with a smaller PDF specifying a high resolution (e.g., 2200 DPI, such that the resulting image is on the order of 20000 pixels by 15000 pixels or more), and received the same crashing error. Repro steps: - Choose File->Open, causing the "Open Image" dialog to appear. - Select a PDF file that contains a single page with a large image that is on the order of 20000 pixels by 15000 pixels, color (haven't tried all variations). -Click "Open" on the "Open Image" dialog, causing the the "Import from PDF" dialog to appear. -Enter "600.000" in the "Resolution" field, specify "pixels/inch". -Choose "Images" in the "Open pages as" field -Verify that the "Width" and "Height" fields show values in the range of 20000 and 15000 pixels or more. -Click the "Import" button on the "Import from PDF" dialog. -Within a few seconds, the following error appears: ========= Plug-in crashed: "file-pdf.exe" (C:\Program Files\GIMP-2.0\lib\gimp\2.0\plug-ins\file-pdf.exe) Opening 'E:\OceTDS1805.pdf' failed: Procedure 'file-pdf-load' returned no return values ========= -Repeat the repro steps with a PDF containing a smaller image, but specify a higher resolution in the "Import from PDF" dialog, such that the resulting image is around 20000 by 15000 pixels. -The same error occurs on import. Expected results: Large PDF images should load correctly; if they load in Acrobat, they should be able to load in the GIMP. If there is a technical limitation to the size of image that the PDF importer can handle, the import plug-in should still not crash, and the error should be friendlier or the "Import from PDF" dialog should not allow the user to exceed the limit. OS - Windows XP Computer - Dell Inspiron 9300, 2GB RAM.
Does this still happen with 2.8.0?
(In reply to comment #1) > Does this still happen with 2.8.0? I tested on the same machine (Dell Inspiron 9300, XP SP3), but with GIMP 2.8.0. The behavior is slightly different, but still not good. I followed the exact repro steps above. The progress bar in the open file dialog did not progress, and quite quickly I got a different error: =========== Calling error for procedure 'gimp-image-insert-layer': Procedure 'gimp-image-insert-layer' has been called with an invalid ID for argument 'layer'. Most likely a plug-in is trying to work on a layer that doesn't exist any longer. =========== After that, a blank image window appeared (with the gray checkerboard background pattern), with dimensions in the window title of "16799x25288" (the correct dimensions according to the 700 DPI setting I chose), and a message in the status bar at the bottom said "Can't work on an empty image, add a layer first". When I loaded the same PDF at 500 DPI, it worked fine. The progress bar in the open file dialog progressed slowly, and when it completed, the correct image appeared in the image window, with the 12000x18063 dimensions shown in the title bar of the window. No error messages appeared. I also repeated this on a Windows 7 virtual machine (running in VMWare Fusion on a Core i7 iMac). On this configuration, I again saw the same error when importing the same PDF at 700 DPI, and the same correct behavior when importing the same PDF at 500 DPI. I repeated this on Gimp 2.6.0 on MAC OSX Lion. I was able to load the same PDF at 700 DPI without errors.
Also just now tried the same PDF at 700 DPI on GIMP 2.8.0 on MAC OSX Lion, and it worked perfectly. So, in summary: The problem no longer displays as a "file-pdf.exe" crash, but it's still an unfriendly error in 2.8.0. The problem occurs both on Windows XP SP3 and Windows 7. The problem appears to not exist on the Mac versions of Gimp, either with 2.8.0 or 2.6.0. One interesting thing to note is that since I originally reported this problem back in 2009, I upgraded the old XP machine to 4GB of memory from the original 2GB. The threshold of image size that causes the error seemed to be unaffected by this upgrade, so it doesn't seem to be a pure out of memory issue. Updated the "Version" on this bug to 2.8.0.
I just tried with GIMP 2.8.2 on Win7, 32 bit in a VM with 2 GB RAM and on Max OS X 10.6 with 8 GB RAM. On Windows: confirming the error message as in comment #3. On both systems: the plugin takes several minutes to process and freezes GIMP. Setting the OS field to 'All' as not only Windows is affected.
Created attachment 227738 [details] [review] bug fix The problem happens when the rendered image has a size greater than 2GB (2^15 x 2^14 * 4) (32K x 16K * 4) or (23170x23170 * 4). There are at least two bugs: first it is necessary to patch pixman, that otherwise fails to create the cairo_image_surface's pixman_image: diff --git a/pixman/pixman-bits-image.c b/pixman/pixman-bits-image.c index 085dd16..2db0346 100644 --- a/pixman/pixman-bits-image.c +++ b/pixman/pixman-bits-image.c @@ -1416,7 +1416,7 @@ create_bits (pixman_format_code_t format, if (_pixman_multiply_overflows_size (height, stride)) return NULL; - buf_size = height * stride; + buf_size = (size_t) height * stride; if (rowstride_bytes) *rowstride_bytes = stride; then with cairo-1.10.2 and the attached patch it is possible to load the pdf attached to https://bugzilla.gnome.org/show_bug.cgi?id=644544#c5, at a resolution of 2400 ppi (19833x28067). With cairo from master, instead it is possible to load the same file as above, but only with anti-aliasing disabled. With anti-aliasing enabled it is cairo to crash in '_fill_xrgb32_lerp_opaque_spans' (cairo-image-compositor.c:2197) probably for the same overflow few lines above. diff --git a/src/cairo-image-compositor.c b/src/cairo-image-compositor.c index 768e3a5..6abbe6f 100644 --- a/src/cairo-image-compositor.c +++ b/src/cairo-image-compositor.c @@ -2183,7 +2183,7 @@ _fill_xrgb32_lerp_opaque_spans (void *abstract_renderer, int y, int h, uint8_t a = spans[0].coverage; if (a) { int len = spans[1].x - spans[0].x; - uint32_t *d = (uint32_t*)(r->u.fill.data + r->u.fill.stride*y + spans[0].x*4); + uint32_t *d = (uint32_t*)(r->u.fill.data + (size_t)r->u.fill.stride*y + spans[0].x*4); if (a == 0xff) { if (len > 31) { pixman_fill ((uint32_t *)r->u.fill.data, r->u.fill.stride / sizeof(uint32_t), r->bpp, The best solution would be to render those big pdf in chunks, avoiding that two processes allocate at the same time more than 2GB and then transfer them in small tiles.
Was this patch (or some other fix for this) applied, please?
An example PDF file that can't be imported with a resolution of 600 ppi on Gimp 2.8.6: http://people.debian.org/~naoliv/misc/mapa_araraquara_outubro2011.pdf
(In reply to comment #6) > Was this patch (or some other fix for this) applied, please? A more extended patch https://bugs.freedesktop.org/attachment.cgi?id=85448 including the bits above is attached to this pixman bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=69014 which is still open. mailing-list discussion: > http://lists.freedesktop.org/archives/pixman/2013-September/thread.html#2915 > http://lists.freedesktop.org/archives/pixman/2013-September/002915.html
The last message in the pixman list was asking for an update to their test suites in order to track the usefulness and correctness of the proposed patch: https://lists.freedesktop.org/archives/pixman/2013-September/002952.html Did anything happen that isn't reflected in their mailing list?
Comment on attachment 227738 [details] [review] bug fix The GIMP side of the patch as attached here is trivial. Will anything break if we commit that now?
No, go ahead and push to both branches. Don't forget the -x in cherry-pick -x :)
Pushed to master commit adae3882d2c9955f9dd62482f9bcdb8456679701 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Sun Feb 19 20:48:39 2017 +0100 Bug 593576 - PDF Import filter: crashes when importing large image PDF or specifying high resolution and gimp-2-8 commit abf4f7560bf9baecd9e111e47c7c82c50e813ef1 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Sun Feb 19 21:01:49 2017 +0100 Bug 593576 - PDF Import filter: crashes when importing large image PDF or specifying high resolution Manually committed to master as commit adae3882d2c9955f9dd62482f9bcdb8456679701 due to code changes there.
Comment on attachment 227738 [details] [review] bug fix This is committed, but the bug will only be fixed if the patches to pixman and cairo are in place, too.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/311.