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


Reply via email to