You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Larry Lynn <la...@workiva.com.INVALID> on 2023/10/26 17:18:40 UTC

java.lang.OutOfMemoryError: Java heap space when converting a PDF to a jpeg

Greetings pdfbox devs.  It's been a long time.  I hope all is well.

First, I'd like to thank you again for all of your work on PDFBox.  It
remains one of the power tools in our stack.


Second, wanted to request assistance with a problem I'm seeing in our
service, which makes heavy use of PDFBox.

We received a PDF from one of our customers with a request to
translate it into JPEG images, one per page.

We've called in to PDFRenderer.renderImageWithDPI().

Execution appears to stall in the PDFBox library.  If we let it run
long enough, we eventually receive a java.lang.OutOfMemoryError: Java
heap space error.

Prior to running out of memory, I see some log messages that I'm not
familiar with

https://github.com/apache/pdfbox/blob/d574e4536d92c743aab308f3580b139b52dcd832/pdfbox/src/main/java/org/apache/pdfbox/rendering/TilingPaint.java#L230

There is also a ticket reference in a code comment near those log
statements: PDFBOX-3653.

I'm wondering if the OOM issues I'm seeing are a recurrence of a
previous, known bug.  I checked the PDFBox dev mailing list and I do
see a recent issue related to memory management and heap space
(PDFBOX-5675), but that issue seems to be unrelated to
TilingPaint.java.


I could use assistance in determining if I've hit a bug in PDFBox, or
if there are other configurations I could set or arguments I could
pass to renderImageWithDPI() to better manage java heap space.


I do not yet have permission from our security organization to share
the PDF which, when used as input, reproduces the java heap space
issues; I am working on getting that permission now..  I've cut down
our reproduction document to 1 page / 196KB, and I know that normally
PDFBox can handle much larger PDFs than that without error.  I suspect
that there is an element inside of the PDF that triggers a bad
execution mode.  One likely culprit is Free-Form Gouraud-Shaded
Triangle Meshes.  I opened the PDF up on Acrobat and ran it through
preflight and I verified that Free-Form Gouraud-Shaded Triangle Meshes
are present in our problem PDF.


Any assistance you can render would be much appreciated.

Thanks and Regards,

Larry Lynn


p.s.  We are currently using java 17 and PDFBox 2.0.28


-- 
*Larry Lynn*
*Staff Software Engineer*
*Workiva Inc*.



*448 E. Main St, Bozeman, MT, 59715*

Re: java.lang.OutOfMemoryError: Java heap space when converting a PDF to a jpeg

Posted by Tilman Hausherr <TH...@t-online.de>.
Hi,

the messages are because of patterns that have a huge memory 
consumption.... coincidentally, I've just changed the message to include

     "increase the property 'pdfbox.rendering.tilingpaint.maxedge'"

the default value is 3000, but in your case you should of course 
*decrease* it (it's possible that your renderings will look terrible). 
Or increase the -Xmx value when starting PDFBox.

Also try to update to 2.0.29 / 3.0.0, or try to display the PDF with 
PDFDebugger.

Tilman

On 26.10.2023 19:18, Larry Lynn wrote:
> Greetings pdfbox devs.  It's been a long time.  I hope all is well.
>
> First, I'd like to thank you again for all of your work on PDFBox.  It
> remains one of the power tools in our stack.
>
>
> Second, wanted to request assistance with a problem I'm seeing in our
> service, which makes heavy use of PDFBox.
>
> We received a PDF from one of our customers with a request to
> translate it into JPEG images, one per page.
>
> We've called in to PDFRenderer.renderImageWithDPI().
>
> Execution appears to stall in the PDFBox library.  If we let it run
> long enough, we eventually receive a java.lang.OutOfMemoryError: Java
> heap space error.
>
> Prior to running out of memory, I see some log messages that I'm not
> familiar with
>
> https://github.com/apache/pdfbox/blob/d574e4536d92c743aab308f3580b139b52dcd832/pdfbox/src/main/java/org/apache/pdfbox/rendering/TilingPaint.java#L230
>
> There is also a ticket reference in a code comment near those log
> statements: PDFBOX-3653.
>
> I'm wondering if the OOM issues I'm seeing are a recurrence of a
> previous, known bug.  I checked the PDFBox dev mailing list and I do
> see a recent issue related to memory management and heap space
> (PDFBOX-5675), but that issue seems to be unrelated to
> TilingPaint.java.
>
>
> I could use assistance in determining if I've hit a bug in PDFBox, or
> if there are other configurations I could set or arguments I could
> pass to renderImageWithDPI() to better manage java heap space.
>
>
> I do not yet have permission from our security organization to share
> the PDF which, when used as input, reproduces the java heap space
> issues; I am working on getting that permission now..  I've cut down
> our reproduction document to 1 page / 196KB, and I know that normally
> PDFBox can handle much larger PDFs than that without error.  I suspect
> that there is an element inside of the PDF that triggers a bad
> execution mode.  One likely culprit is Free-Form Gouraud-Shaded
> Triangle Meshes.  I opened the PDF up on Acrobat and ran it through
> preflight and I verified that Free-Form Gouraud-Shaded Triangle Meshes
> are present in our problem PDF.
>
>
> Any assistance you can render would be much appreciated.
>
> Thanks and Regards,
>
> Larry Lynn
>
>
> p.s.  We are currently using java 17 and PDFBox 2.0.28
>
>