[Varnish] #1188: Assert error in hcb_insert(), hash_critbit.c line 212: Condition((y)->magic == 0x125c4bd2) not true.

[Varnish]

#1188: Assert error in hcb_insert(), hash_critbit.c line 212:
Condition((y)->magic == 0x125c4bd2) not true.
----------------------+--------------------
 Reporter:  flies     |       Owner:
     Type:  defect    |      Status:  new
 Priority:  lowest    |   Milestone:
Component:  varnishd  |     Version:  3.0.3
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------
Changes (by phk):

 * priority:  normal => lowest


Comment:

 As always I'm not ruling out that there is a bug, but given how much
 beating up the critbit code gets on all the varnish installations out
 there, I find it very improbable that your precise site can trigger a
 unknown and obscure bug this often.

 I spent some time staring at the relevant code, and the one thing that
 keeps popping up in my mind is that the trouble you see is _exactly_ what
 you would expect to see if there is a "use after free" mistake somewhere
 else in the program, (which in varnish' case includes the compiled VCL,
 any vmods and any libraries they use.)

 I have taken a quick look at the vmod_redis in github, and I don't spot
 any obvious use-after-free bugs, but I think that vmod leaks memory big
 time:  All the strdup() returns never get freed, and I don't see where the
 redisContext's get freed either.

 I'm going to leave this ticket open, but I will assign it "lowest"
 priority, because there is no way I can debug this other than a total code
 source-code inspection.

 What I would suggest to you, is to build varnish from source, and put a
 check before the assert which will record what the value actually is, when
 it does not match the expected magic marker.  Sometimes that value may
 give a clue to what code overwrote the value that should have been there.

 The other thing you can try is to use a the "classic" hash instead of
 critbit, it will not make the bug go away, but it will cause it to have a
 different impact, which again could offer clues to what/where the bug
 actually is.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1188#comment:1>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator