[
https://issues.apache.org/jira/browse/PDFBOX-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280278#comment-14280278
]
John Roche commented on PDFBOX-2596:
------------------------------------
Having looked at the code again after reading this comment I assume you mean
the PDDocument created by PDDocument::load(InputStream) - this should be
explicit, and I don't just mean in your comments. If an object is required to
have some method called on it after being created inside a method call (i.e.
the load call) then it should definitely say so in the javadocs.
I suspect the clearing of objects IS the issue here. Having debugged through
what the close() call does (in this specific case) it doesn't seem to close any
actual active, live IO streams, so all it's doing is nullifying objects,
emptying lists and setting primitive member variables to 0. None of that is
needed, or desired, or best practise. The one active IO stream it does close
is one that it shouldn't, namely the one that is passed in.
> NullPointerException in RandomAccessFileInputStream
> ---------------------------------------------------
>
> Key: PDFBOX-2596
> URL: https://issues.apache.org/jira/browse/PDFBOX-2596
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 1.8.8
> Reporter: John Roche
>
> Line 94 contains a synchronized(file) that throws a NullPointerException
> under some strange circumstances that I haven't been able to fully identify
> yet. I have downloaded the 1.8.8 source and the fix I used is simply to add
> "&& file != null" to the previous if statement.
> I can reproduce this bug with live user data, but I haven't been able to with
> test data yet. It happens when I try to create a pdf with 36 pages that have
> an image, some drawn coloured boxes and some text, on each page. If I remove
> some of the pages before I call save(File) it doesn't happen - depending on
> which pages I remove it can be ok with up to 26 pages, or break with fewer.
> Quite strange. I suspect it's to do with the size of the data as opposed to
> the number of pages.
> I will continue to investigate, since there seems to be some underlying
> issue, but for now I guess the null protection should be ok to add?
> Thanks,
> John
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
