h2o_http2_conn_unregister_stream assert on shutdown
#2000
Conversation
|
I'm confused. Are you suggesting that we have a case where a stream is in REQ_PENDING state but not linked to |
That's right in https://github.com/h2o/h2o/blob/master/lib/http2/connection.c#L220 we might exit before linking the request to |
I think so. Possibly by moving the code that resets the stream based on the comparison of stream ID and max_open outside of the function. |
2229016 to
4540171
Compare
|
@kazuho How does 4540171 look? |
|
@deweerdt Looks fine, with the exception that I think we need to do the same for the other path that calls Maybe we should create a function that detects stream IDs above the value sent in GOAWAY and resets a stream, then call the function from the two places that call Honestly speaking I think there could be a better way to handle streams that we are ignoring. There's no need to buffer the request as we do now (though note that the server needs to maintain some state to avoid sending RST_STREAM in response to every frame it receives). But I think we can live with adjusting the current approach, at least for the time being. |
`h2o_http2_conn_unregister_stream` wants `_refs.link` set if the state is pending. However, when we sent `GOAWAY` (for draining), we don't bother linking said struct member in `execute_or_enqueue_request_core`. This fixes the issue by not switching the stream to `REQ_PENDING` if we're going to reset it.
4540171 to
156a70a
Compare
Thank you for the suggestion, implemented in 156a70a |
`h2o_http2_conn_unregister_stream` assert on shutdown
h2o_http2_conn_unregister_streamwants_refs.linkset ifthe state is pending. However, when we sent
GOAWAY(fordraining), we don't bother linking said struct member in
execute_or_enqueue_request_core. This fixes the issue by transitioningthe stream to
END_STREAMinh2o_http2_stream_reset, making thelinking of
_refs.linkoptional.