[Varnish] #1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
Varnish
varnish-bugs at varnish-cache.org
Wed Mar 4 18:51:18 CET 2015
#1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
-------------------------+----------------------------------------
Reporter: cache_layer | Owner: Poul-Henning Kamp <phk@…>
Type: defect | Status: reopened
Priority: normal | Milestone:
Component: build | Version: 4.0.3
Severity: normal | Resolution:
Keywords: |
-------------------------+----------------------------------------
Comment (by geoff):
A brief update (because I'm not sure if I'm up-to-date with fgsch at the
moment):
I can confirm that with fgsch's patch of February 26th, both versions of
the VTC test pass with 4.0.3. Nevertheless, I can get a running Varnish
with the patch to crash on the same assertion failure. Right now I'm
frankly at a loss as to how construct a VTC that reproduces the error.
The offending response that causes the crash is still very similar:
* ESI-included (at ESI level 4, as it happens)
* Response status 204 and empty response body
* No Content-Length header (Content-Length==0 follows implicitly from 204)
* Accept-Encoding:gzip in the request, so Content-Encoding:gzip is in the
response
All of that can be reproduced in a VTC, ('txresp -nolen' causes the beresp
to have no Content-Length header), but nevertheless I haven't been able to
get a VTC to cause the crash after the patch has been applied (and fgsch
has told me the same).
I have sent varnishlogs and the panic message to fgsch (haven't attached
them here because I'd have to anonymize them).
We are able to work around the problem in VCL:
* In vcl_backend_response(), if the response is ESI-included and
beresp.status==204, then unset beresp.http.Content-Encoding, and set
beresp.do_gzip to false.
* For synthetic, ESI-included responses: In vcl_synth(), if req.can_gzip
is true and resp.http.Content-Encoding does not include "gzip", then set
resp.http.Content-Encoding to "gzip". (Don't remember at the moment why
this part was necessary, just that it didn't work without it.)
--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1602#comment:9>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
More information about the varnish-bugs
mailing list