Closed simonvik closed 6 years ago
One possible thing that would definitely trigger a panic like this is if we were unable to schedule a stream after being waitlisted. The current error handling in h2_reembark
does a somewhat premature Req_Release
, which will release the req and thus zero the workspace that is the storage for the corresponding h2_req
.
This could explain why the panic is showing two separate streams both with ID 0, and also why the magic test failed.
I'll cook up a patch to sort out the h2_reembark
logic.
test case:
varnishtest "#2563: Panic after reembark failure"
barrier b1 cond 2
barrier b2 cond 2
server s1 {
rxreq
expect req.url == "/foo"
send "HTTP/1.0 200 OK\r\nConnection: close\r\n\r\n"
delay .2
barrier b1 sync
delay .2
send "line1\n"
delay .2
barrier b2 sync
send "line2\n"
} -start
varnish v1 -vcl+backend {
sub vcl_backend_response {
set beresp.do_stream = false;
}
} -start
varnish v1 -cliok "param.set feature +http2"
varnish v1 -cliok "param.set debug +failresched"
varnish v1 -cliok "param.set debug +waitinglist"
varnish v1 -cliok "param.set debug +syncvsl"
client c1 {
txreq -url "/foo" -hdr "client: c1"
rxresp
expect resp.status == 200
expect resp.bodylen == 12
expect resp.http.x-varnish == "1001"
} -start
barrier b1 sync
client c2 {
stream 1 {
txreq -url "/foo" -hdr "client" "c2"
delay .2
barrier b2 sync
rxrst
expect rst.err == REFUSED_STREAM
} -run
} -run
client c1 -wait
varnish v1 -vsl_catchup
varnish v1 -expect busy_sleep >= 1
varnish v1 -expect busy_wakeup == 0
varnish v1 -expect busy_killed == 1
Running on ubuntu 16.04 Varnish built from master, commit 1506c55872ac31dee1a7884e5631bebd505351e0 nm-output.txt