| Summary: | [Patch] Add support for next Actions in PDF Forms | ||
|---|---|---|---|
| Product: | poppler | Reporter: | Andre Heinecke <aheinecke> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | medium | CC: | nate |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Patch to add support for next actions
Patch to add support for next actions - Update 1 |
||
|
Description
Andre Heinecke
2018-03-27 07:23:19 UTC
This is one of those cases where malformed PDF can loop poppler forever creating a loop in the Next array by using an Array of references to dicts, i.e. something like (non valid PDF syntax for sure ) 1 0 obj Dict Link stuff /Next [ 1 0 R ] stuff This would end up in a parsing loop, and it's worse the loop can be introduced at any time 1 0 obj Dict Link stuff /Next [ 2 0 R ] stuff 2 0 obj Dict Link stuff /Next [ 1 0 R ] stuff So what we need to do is something similar to what we do in other cases an std::set<int> seen that we pass to the parseAction, then when parsing the array call getNF, if it's a ref check/add it against seen, if it's a dict, just carry on and if it's a ref and not seen before fetch it and carry on too. If you grep for std::set you'll find some cases around the code that deal with that. I wish we had a generic way to do it since it's kind of cumbersome to do every time we're parsing a tree of objects of the same type :/ Created attachment 138704 [details] [review] Patch to add support for next actions - Update 1 Yes. I thought "well we are in PDF Form / JavaScript Land" anyway but you are right, of course, segfaulting with an endless memory allocation is never nice :-P I've updated the patch accordingly and update the visibilitytest.pdf document that I use in the okular unittest to contain such a loop. This allowed me to reproduce a segmentation fault without this change. Could you extend / add the visibilitytest.pdf to also contain an array of next actions that show such a loop? I was unable to construct one. I could replace a ref to a next action but when I tried to change it to an array I only produced invalid pdfs. So the second codepath relating to the Arrays is untested :-/ pushed (with some improvements) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.