Ryan Rupp created PDFBOX-4906:
---------------------------------
Summary: PDOptionalContentProperties hasGroup can null pointer if
OCGs data is missing
Key: PDFBOX-4906
URL: https://issues.apache.org/jira/browse/PDFBOX-4906
Project: PDFBox
Issue Type: Bug
Affects Versions: 2.0.13
Reporter: Ryan Rupp
I've noticed the following null pointer exception can happen on scanned
documents when we're checking if it has a layer of a given name:
{code:java}
java.lang.NullPointerExceptionjava.lang.NullPointerException at
org.apache.pdfbox.pdmodel.graphics.optionalcontent.PDOptionalContentProperties.getGroupNames(PDOptionalContentProperties.java:227)
at
org.apache.pdfbox.pdmodel.graphics.optionalcontent.PDOptionalContentProperties.hasGroup(PDOptionalContentProperties.java:245)
{code}
Looking into this, it happens because for these particular documents the
following line returns null -
[https://github.com/apache/pdfbox/blob/da378798e5f2c8a1394725518db478f7ffaf5177/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/optionalcontent/PDOptionalContentProperties.java#L227]
and subsequently gets dereferenced
It may be that these files are just generated in an invalid way (unfortunately
I cannot provide them as it contains customer information). Anyway, looking at
the code other methods getGroup(name) call a private method getOCGs that
safeguards against the null case by defaulting it then, see here -
[https://github.com/apache/pdfbox/blob/da378798e5f2c8a1394725518db478f7ffaf5177/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/optionalcontent/PDOptionalContentProperties.java#L118]
So maybe getGroupNames() (which hasGroup uses) can just use that as a
safeguard? Anyway, the workaround was to replace our hasGroup(name) check with
getGroup(name) != null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
