[Varnish] #1762: VSL API: endless loop and out of memory in vtx_scan() on forced synthetic transactions
Varnish
varnish-bugs at varnish-cache.org
Tue Jul 14 04:58:43 CEST 2015
#1762: VSL API: endless loop and out of memory in vtx_scan() on forced synthetic
transactions
----------------------+----------------------------------
Reporter: geoff | Owner:
Type: defect | Status: closed
Priority: normal | Milestone: Varnish 4.0 release
Component: varnishd | Version: 4.0.3
Severity: critical | Resolution: fixed
Keywords: |
----------------------+----------------------------------
Changes (by slink):
* status: reopened => closed
* resolution: => fixed
Comment:
Replying to [comment:3 geoff]:
> This problem is not solved, since the endless loop and ENOMEM could
happen again if a VXID mismatch occurs for any other reason.
The specific issue was with this section of the code:
{{{
vtx_scan(struct VSLQ *vslq, struct vtx *vtx)
{
// [....]
if (VSL_ID(ptr) != vtx->key.vxid) {
(void)vtx_diag_tag(vtx, ptr, "vxid mismatch");
continue;
}
}}}
If we find a log chunk linked to our vtx with a vxid other than the vtx'es
vxid, vtx_diag_tag will get called and nothing is wrong with that.
vtx_diag_tag -> vtx_synth_rec will use the vtx'es vxid for the synth
records. I don't see a risk of an infinite loop here if vtx->key.vxid is
correct.
The specific issue here was that vtx->key.vxid was _not_ correct in 4.0.3
without the VXID macro fix: For instance Link records could contain vxids
with the client/backend bit set, so vtxes with these bad vxids could get
created.
The comparison above between the vtx vxid and VSL_ID() assumes that the
vtx vxid never contains client/backend bits, so it always reported a
mismatch for this case.
So I think we have good reason to assume that this issue's root cause is
really fixed.
--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1762#comment:4>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
More information about the varnish-bugs
mailing list