[
https://issues.apache.org/jira/browse/PDFBOX-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238957#comment-16238957
]
Tilman Hausherr commented on PDFBOX-3990:
-----------------------------------------
[~barsk] your fix is ok. I tested it myself too yesterday afternoon. There is
no code ownership. We try to review each others changes. You can get a snapshot
here:
https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.9-SNAPSHOT/
The bug was related to a corner case.
Here's the algorithm:
{quote}
The RunLengthDecode filter decodes data that has been encoded in a simple
byte-oriented format based on run length. The encoded data shall be a sequence
of runs, where each run shall consist of a length byte followed by 1 to 128
bytes of data. If the length byte is in the range 0 to 127, the following
length + 1 (1 to 128) bytes shall be copied literally during decompression. If
length is in the range 129 to 255, the following single byte shall be copied
257 - length (2 to 128) times during decompression. A length value of 128 shall
denote EOD.
{quote}
[~lehmi] why the assignment? I also suggest to check the return value of
dupByte (line 63).
> Rendering will never complete
> -----------------------------
>
> Key: PDFBOX-3990
> URL: https://issues.apache.org/jira/browse/PDFBOX-3990
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.8
> Environment: Java 1.8
> Reporter: Kristian Jörg
> Assignee: Andreas Lehmkühler
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: D90296482_20171102.PDF
>
>
> I have a PDF file that I am attempting to render with:
> {code:java}
> PDFRenderer renderer = new PDFRenderer(document);
> for (int i = 0; i < 2; i++ ) { // the document is two pages, code simplified
> BufferedImage image = renderer.renderImageWithDPI(i, dpi, ImageType.RGB);
> }
> {code}
> However, the code never returns. When I pause execution (in Eclipse) I see
> that execution never leaves the decode() method of
> org.apache.pdfbox.filter.RunLengthDecodeFilter.
> The problem is that the inner loop of while (amountToCopy > 0) in bold below
> is never executed because the stream has come to EOF! That means that the int
> compressedRead get a negative value and amountToCopy is _*added *_to instead
> of being subtracted from.
> The loop seems to eventually step out of itself, Probably when the integer
> warps around when reaching it's max (?)
> The problem is easy to catch if setting a conditional breakpoint on
> compressedRead == -1.
> I'll include the PDF. The problem arises on page 2.
> {code:java}
> public DecodeResult decode(InputStream encoded, OutputStream decoded,
> COSDictionary parameters, int index)
> throws IOException
> {
> int dupAmount;
> byte[] buffer = new byte[128];
> while ((dupAmount = encoded.read()) != -1 && dupAmount !=
> RUN_LENGTH_EOD)
> {
> if (dupAmount <= 127)
> {
> int amountToCopy = dupAmount + 1;
> int compressedRead;
> * while(amountToCopy > 0)
> {
> compressedRead = encoded.read(buffer, 0, amountToCopy);
> decoded.write(buffer, 0, compressedRead);
> amountToCopy -= compressedRead;
> }*
> }
> else
> {
> int dupByte = encoded.read();
> for (int i = 0; i < 257 - dupAmount; i++)
> {
> decoded.write(dupByte);
> }
> }
> }
> return new DecodeResult(parameters);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
