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
