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

Reply via email to