Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
http2 assert drain_total and state.drain gets out of sync #1680
I can reproduce an issue with http2 in curl 7.53 (and seemingly nothing has changed in this area in 7.54)
I did this
I expected the following
No asserts, instead I get this one every time:
http2_handle_stream_close: Assertion `httpc->drain_total >= data->state.drain' failed.
I believe it's related to retrying of requests since it seems to shortly follow this debug statement every time:
Issue another request to this URL: ...
It seems more or less innocuous to me and maybe the code that checks that state.drain > total_drain could just be defensive but I'm not 100% sure what unintended consequences that might have.
I compiled the app like this:
/usr/local/x86_64-toolchain-linux-gnu-master/bin/x86_64-toolchain-linux-gnu-gcc -I/usr/local/x86_64-toolchain-linux-gnu-master/include/ main.c -lcurl -lnghttp2 -L/usr/local/x86_64-toolchain-linux-gnu-master/lib -lssl -lcrypto -lz -Wl,-rpath,/usr/local/x86_64-toolchain-linux-gnu-master/lib
In the attached zip there is a small example program (main.c), an nginx.conf and a log from a run with --verbose (lots and lots of output, it'll kill your terminal if you don't redirect)
I am facing same issue in more or less the same setup.
Few additional data points if they help.
I am getting the same assertion failure, once every couple of hours for my application(details below)
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.5 brotli/1.0.2 c-ares/1.13.0 nghttp2/1.29.0
A little detail about my application -
I also use http multiplexing(but not pipelining) by setting the suitable option on the multi-handle and k out of m requests could be going to the same server i.e multi-plexed over the same TCP connection using http2.
After max n milliseconds I remove all the easy handle using curl_multi_remove_handle API regardless of whether individual transfers are "DONE" or not.
The same underlying connection is re-used(which prior to version 7.58 was not the case, #2237) for the next subsequent request to the server.
Here is the backtrace
(gdb) p httpc->drain_total