named crashed (mem.c:1099: INSIST(ctx->stats[i].gets == 0U) failed)
freaknetboy at yahoo.com
Thu May 5 20:07:24 UTC 2011
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.
----- 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)
> > daemon:crit named: mem.c:1099: INSIST(ctx->stats[i].gets == 0U)
> > daemon:crit named: 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
More information about the bind-users