[
https://issues.apache.org/jira/browse/PDFBOX-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272629#comment-14272629
]
Tilman Hausherr edited comment on PDFBOX-2596 at 1/12/15 11:05 PM:
-------------------------------------------------------------------
Putting a nullcheck is just hiding the symptom. The "file" variable is
initialized by its constructor, so the real question is - why is it constructed
with a null argument?
In the worst case, something is missing in your PDF file and you're not even
noticing it.
Btw, does your application use multithreading? This is not supported, i.e. you
can't do several things at the same time with one PDDocument.
was (Author: tilman):
Putting a nullcheck is just hiding the symptom. The "file" variable is
initialized by its constructor, so the real question is - why is it constructed
with a null argument?
Btw, does your application use multithreading? This is not supported, i.e. you
can't do several things at the same time with one PDDocument.
> 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)
