What steps will reproduce the problem?
1. compile and run `pdfium_test` with attached pdf (with or without any of the
image output flags)
2. watch memory size (or use dtrace/Instruments.app)
3. inspect the rendered images
What is the expected output?
`pdfium_test` should iterate through the pages of a PDF and keep memory usage
at a consistent level while parsing and rendering each page to an image (e.g.
memory usage should not grow proportionally to the # of pages in the document).
What do you see instead?
In a memory constrained environment (say an ubuntu vm w/ 512mb ram),
`pdfium_test` consumes memory until the system invokes the OOMKiller.
After PDFium is modified with the attached patch (which addresses the memory
leak), `pdfium_test` does not render image contents of some pages (in
comparison to OSX's Preview, Firefox's PDF.js, graphicsmagick+ghostscript which
do so fine).
What version of the product are you using? On what operating system?
We're building from master, and have tested against OSX 10.10 and ubuntu 14.04
(trusty) vm. Additionally, the PDF viewer in Google Chrome (stable) exhibits
the same behavior (high memory usage, pages are rendered as blank).
Please provide any additional information below.
We've identified a memory leak and some problematic error handling behavior in
the CPDF_DIBSource::LoadJpxBitmap in
/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp
LoadJpxBitmap allocates a jpeg decoder, and in three cases designed to handle
decoding errors, exits without freeing the decoder. The missing deallocations
are included in the attached patch.
Beyond that, the attached PDF appears to have colorspace issues which PDFium
isn't happy with (we haven't had time to spelunk the meaning of the errors, but
CPDF_DIBSource::LoadJpxBitmap is exiting through the conditional on line 651),
and consequently, the relevant images on the page are not rendered.
We suspect that other PDF renders have some sort of fallthrough/fallback to
handle cases like these, as a variety of other renders we have tested with
display the attached PDF fine, although we have not identified what handling
other renderers perform.
Attached screenshot provides a stack trace for the runaway allocations (the
test run was performed from the full 247 page document from which the attached
PDF is excerpted). We can provide the Instruments.app trace file if requested
(not attached here because of attachment size)
Original issue reported on code.google.com by t...@knowtheory.net on 3 Mar 2015 at 4:28
Original issue reported on code.google.com by
t...@knowtheory.neton 3 Mar 2015 at 4:28Attachments: