[
https://issues.apache.org/jira/browse/PDFBOX-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14279904#comment-14279904
]
John Hewson edited comment on PDFBOX-2596 at 1/16/15 7:26 AM:
--------------------------------------------------------------
By not holding a reference to the PDDocument you created, it's impossible for
you to call close(). While we do call close() in the finalizer, it's [not
something you should rely
on|https://weblogs.java.net/blog/jfalkner/archive/2007/07/blarg27_dont_us.html].
You _must_ hold a reference to the PDDocument and call close() yourself.
The clearing of the objects which you noticed in COSDocument#close() has just
been fixed in the trunk by PDFBOX-2592, but that's not the issue here. When you
close a COSDocument (or the finalizer does it for you) then any COSStreams
obtained from it become unreadable, so your PDPage objects are unreadable - in
1.8 this gives you an NPE, but in the trunk it is now a proper IOException.
was (Author: jahewson):
By not holding a reference to the PDDocument you created, it's impossible for
you to call close(). While we do call close() in the finalizer, it's not
something you should rely on. -You _must_ hold a reference to the PDDocument
and call close() yourself.
The clearing of the objects which you noticed in COSDocument#close() has just
been fixed in the trunk by PDFBOX-2592, but that's not the issue here. When you
close a COSDocument (or the finalizer does it for you) then any COSStreams
obtained from it become unreadable, so your PDPage objects are unreadable - in
1.8 this gives you an NPE, but in the trunk it is now a proper IOException.
> 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)
