Closed
Description
openedon Jan 19, 2017
I am the author of pom, now I use pom to implement a PDF parser and get some surprising result:
git clone https://github.com/J-F-Liu/lopdf.git
cd lopdf/pdfutil
cargo build
cargo run -- decompress -i /home/junfeng/Downloads/OpenGEX.1.1.2.pdf
The output is:
▶ cargo run -- decompress -i /home/junfeng/Downloads/OpenGEX.1.1.2.pdf
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/pdfutil decompress -i /home/junfeng/Downloads/OpenGEX.1.1.2.pdf`
Open /home/junfeng/Downloads/OpenGEX.1.1.2.pdf
xref has 75 entires
...
xref has 75 entires
xref has 139815792274816 entires
xref has 75 entires
xref has 75 entires
xref has 139815791991872 entires
xref has 75 entires
xref has 75 entires
xref has 139815792057408 entires
xref has 75 entires
xref has 75 entires
xref has 139815792057408 entires
xref has 75 entires
xref has 139815792057696 entires
...
xref has 139815792057696 entires
xref has 75 entires
Do decompress
xref is the same BTreeMap variable captured in nested closures printing its len().
Notice these big random numbers, probably caused by wrong pointers.
Try another PDF file:
▶ cargo run -- decompress -i /home/junfeng/Downloads/rfc7159.pdf
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/pdfutil decompress -i /home/junfeng/Downloads/rfc7159.pdf`
Open /home/junfeng/Downloads/rfc7159.pdf
xref has 234 entires
xref has 234 entires
xref has 234 entires
xref has 234 entires
xref has 234 entires
xref has 139647596457568 entires
This time the parser actually accesses entry in xref, the program failed and exited without printing any panic message!
The download links of these example PDF files are:
You can play with the code, add more debug infos, please find out the root cause.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Assignees
Labels
No labels