named crashed (mem.c:1099: INSIST(ctx->stats[i].gets == 0U) failed)

Fr34k freaknetboy at yahoo.com
Thu May 5 20:07:24 UTC 2011


Hello All,

Thanks Evan.

Should the Community expect a BIND 9.7.3 train update/maintenance release which, 
among other things, addresses this mem.c issue?

If so, any ETA?

It is not my intent to sound pushy.  Let me explain.

We were in the process of rolling 9.7.3 out but we stopped figuring a 
maintenance release may be available in the near future.
We have a sense of urgency as 9.7.3 fixes some things broke in 9.7.2-P2; 
however, we'd like to deploy the latest/greatest 9.7 version available.

Alternatively, I would entertain the idea of rolling out an update/maintenance 
release of 9.8 if such an animal may emerge soon.
I mention this in case this is relevant to any recommendations ISC may have.

Thoughts?


Thank you.


----- Original Message ----
> From: Evan Hunt <each at isc.org>
> To: "Khuu, Linh   Contractor" <Linh.Khuu at ssa.gov>
> Cc: Bind Users Mailing List <bind-users at lists.isc.org>
> Sent: Tue, April 12, 2011 10:50:05 AM
> Subject: Re: named crashed (mem.c:1099: INSIST(ctx->stats[i].gets == 0U) 
>failed)
> 
> > daemon:crit named[221184]: mem.c:1099: INSIST(ctx->stats[i].gets == 0U)  
>failed
> > daemon:crit named[221184]: exiting (due to assertion  failure)
> > 
> > named restarted fine and running without any problem.  Does anyone have
> > any idea why named crashed with these errors??? Is it a  bug in bind??
> > We're running bind 9.7.3.
> 
> Yes, it's definitely a  bug (named should never have an assertion failure).
> Please send as much  information as you can (named -V output, named.conf,
> logs, etc) to bind9-bugs at isc.org.
> 
> In this case,  that doesn't look like a crash to me, though.  That's the
> error you see  when you're shutting down named in the usual way (i.e.,
> kill -INT or rndc  stop) and it detects during shutdown that some memory
> had been allocated but  not freed.  If you run named with the "-m record"
> option, it will list  in the log exactly where all the unfreed blocks of
> memory had been  allocated.  That record-keeping has an impact on
> performance, but it can  help a lot with locating the problem.
> 
> -- 
> Evan Hunt -- each at isc.org
> Internet Systems Consortium,  Inc.
> _______________________________________________
> bind-users mailing  list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 



More information about the bind-users mailing list