[
https://issues.apache.org/jira/browse/PDFBOX-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743514#comment-17743514
]
Andreas Lehmkühler commented on PDFBOX-3712:
--------------------------------------------
I had to dig a little bit but I've found the reason fore the change of
behaviour. The trunk uses a ByteArrayOutputStream/ByteArrayInputStream to
decompress streams. Those are backed by a byte array and the maximum size is
Integer.MAX_VALUE = 2^31-1 ~ 2GB. The stream in question as a size of 3.1GB so
that there will be an overflow even if one provides enough memory using -Xmx
The 2.* versions are using a ScrachFileBuffer which consists of more or less
chunks which is limited only by the available amount of memory/disk space. Even
a stream with 3.1GB isn't a problem at all, it take some time but in the end
rendering works. I guess the the debugger uses another path to get the content
of a stream and may fail because it doesn't use a SrcatchFileBuffer
> PDFBox goes into an infinite loop with this PDF
> -----------------------------------------------
>
> Key: PDFBOX-3712
> URL: https://issues.apache.org/jira/browse/PDFBOX-3712
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
> Affects Versions: 2.0.4
> Reporter: Dirk Groeneveld
> Priority: Major
> Attachments: PDFBOX-3712-page6-rendered.png
>
>
> The PDF at
> https://pdfs.semanticscholar.org/2095/e3df01fc32e0bff982a1e79600d5bcf10b81.pdf
> puts PDFBox into an infinite loop.
> This is roughly my code:
> {quote}
> final PDDocument pdDoc = PDDocument.load(inputStream);
> PDFTextStripper stripper = new PDFTextStripper();
> stripper.getText(pdDoc);
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
