[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