QUIC: fixed accessing deleted rbtree node when closing streams. #401
Conversation
A decoder stream can be closed on error as part of closing request streams. Closes nginx#369.
| return NGX_OK; | ||
| } | ||
|
|
||
| node = ngx_rbtree_min(tree->root, tree->sentinel); |
There was a problem hiding this comment.
This may not give the actual next node, but the first one which was not closed. In this case for all such non-closed nodes read handler will be called again.
There was a problem hiding this comment.
Indeed, this is seemingly possible for stream requests blocked on AIO, in which case termination doesn't happen immediately.
On the other hand, I don't see how this differs from QUIC close handler posted or scheduled to resume QUIC connection close. In this case, stream read handlers for non-closed nodes are called again as well. This is arguably another bug, ngx_quic_close_streams() should be placed under !qc->closing.
There was a problem hiding this comment.
On a related note, see also 9a3ec20 where calling read handlers again already happens to facilitate HTTP/2 connection draining in lingering, and I assume this will always happen after converting ngx_quic_close_streams() to posted events.
The question is why calling handlers again may be bad.
I generally agree with you. |
A decoder stream can be closed on error as part of closing request streams. Closes #369.