[9] RFR of 8143394: PushbackReader throws NullPointerException

Daniel Fuchs daniel.fuchs at oracle.com
Fri Dec 4 08:48:20 UTC 2015


Hi Brian,

The fix looks good to me! Good that you were able to find these
other classes where the same issue appeared.
I see that FilterReader.close() calls in.close(). Hopefully wrapping
this call (from PushbackReader) in a synchronized(lock) block
won't be an issue. I wonder if:

  248     public void close() throws IOException {
249 synchronized (lock) {
  250             buf = null;
  251         }
252 super.close(); 253 }

would be a safer implementation. I don't know the java.io code
in depth - so that's just a question...

The only other possible issue I spotted is in the test:

Because readers[0] is set by one thread and read by both then using
an array without synchronization is not thread safe. I would
advise using an AtomicReference instead.

Best regards,

-- daniel

On 12/4/15 1:23 AM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8143394
> Patch:	http://cr.openjdk.java.net/~bpb/8143394/webrev.00/
>
> The NPE apparently occurred in PushbackReader because a call to close() was made after the conditional at line 72 was evaluated to ‘false’ but before the variable ‘buf’ was dereferenced at line 87. The fix is to change close() to use the ‘lock’ variable as in the other methods. Similar problems were found to exist in CharArrayReader and StringReader. The test reliably reproduces the NPE in all three classes with the NPE in PushbackReader being reproduced frequently and the NPE in the other classes less so.
>
> Thanks,
>
> Brian




More information about the core-libs-dev mailing list