[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