Assertion Failure

Rich Goodson rgoodson at gronkulator.com
Thu Jan 15 21:57:17 UTC 2009


I had the same issue on one of my caching resolvers just yesterday for  
the first time.  This is one of the lowest utilized servers out of 6  
that are all on identical hardware and identical versions of BIND  
(9.4.3).

Jan 14 17:46:38 wdmdc-dns-dts2 named[1415]: [ID 873579 daemon.crit]  
name.c:1714: INSIST(nlabels == name->labels) failed
Jan 14 17:46:38 wdmdc-dns-dts2 named[1415]: [ID 873579 daemon.crit]  
exiting (due to assertion failure)

One thing I CAN tell you, however, is that I was testing a script on  
this box earlier in the day and ran
rndc -cache dumpdb
probably around a dozen times during the two hours I was testing the  
script.  This would have been between 3 and 5pm that I was doing my  
testing and the named process died at 5:46, as you can see from the  
log entries.

   -rich

On Jan 14, 2009, at 2:35 PM, JINMEI Tatuya / 神明達哉 wrote:

> At Wed, 14 Jan 2009 09:16:53 -0600,
> Timothy Holtzen <tah at NebrWesleyan.edu> wrote:
>
>> Last night one of our name servers stopped unexpectedly.  Looking  
>> in the
>> logs I found the following messages.
>>
>> Jan 13 20:15:01 foo named[29625]: statschannel.c:696: INSIST(xmlrc  
>> >= 0)
>> failed
>> Jan 13 20:15:01 foo named[29625]: exiting (due to assertion failure)
>>
>> Anyone have any idea why this would happen or how I can keep it from
>> happening again?  I notice that the failure is happening in
>
> This assertion failure was triggered due to a failure of
> xmlTextWriterEndElement().  In the current we naively assume this
> library call always succeed, which is, of course, a bad practice.
> We'll eventually have to update the code to catch the error and
> recover from it.
>
> On the other hand, this call should normally succeed, especially in
> the way we use it.  One of few possible causes of failure I can think
> of is a memory allocation failure occurring in the libxml2 library.
> So, I suggest you check memory footprint of your named process.  If it
> consumes much of available memory, one possible workaround is to
> suppress the memory usage, e.g., by adjusting max-cache-size.
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090115/01d5abc6/attachment.html>


More information about the bind-users mailing list