Details
-
Bug
-
Resolution: Done
-
Major
-
2.2.7.Final
-
None
-
None
Description
Twice we have observed the following NPE:
java.lang.NullPointerException
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:1015)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:990)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$1.run(AbstractFramedChannel.java:1001)
at io.undertow.server.protocol.framed.AbstractFramedChannel$1.run(AbstractFramedChannel.java:144)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
Investigation pointed to a data race around readData. In particular, it looks like here, readData is null before the &&, and null afterward, eliciting the NPE.
The only un-synchronized modification I see of readData is here, and I consider this the prime suspect, but I'm not yet familiar enough with the workings and lifecycle of the AbstractFramedChannel to be 100% certain.
If pressed, I would suggest that:
- AbstractFramedChannel.close be synchronized, and
- Remaining instances of (readData != null && ...) be wrapped in appropriate synchronized blocks.
If I can convince myself of the proper fix I'll contribute it. In any case, thanks in advance for taking a look and providing feedback.
