named assertion failure

[Cathy Almond]

On 06/01/2015 04:11, James Brown wrote:
> Running BIND 9.10.1-P1  on Mac OS X 10.10.1. It’s been running fine - no
> problems until this morning, when I got:
> 
> 
> 06-Jan-2015 01:33:33.356 transfer of 'rpz.spamhaus.org/IN/external'
> <http://rpz.spamhaus.org/IN/external'> from 199.168.90.51#53: Transfer
> completed: 1 messages, 486 records, 11827 bytes, 0.292 secs (40503
> bytes/sec)
> 06-Jan-2015 01:33:33.463 rpz.c:463: REQUIRE(*cnt > 0) failed, back trace
> 06-Jan-2015 01:33:33.482 #0 0x10f97917d in isc_thread_yield()+0xf6ad05d
> 06-Jan-2015 01:33:33.495 #1 0x10fbf54aa in isc_thread_yield()+0xf92938a
> 06-Jan-2015 01:33:33.495 #2 0x10fab7eac in isc_thread_yield()+0xf7ebd8c
> 06-Jan-2015 01:33:33.495 #3 0x10fab678b in isc_thread_yield()+0xf7ea66b
> 06-Jan-2015 01:33:33.495 #4 0x10fa34c94 in isc_thread_yield()+0xf768b74
> 06-Jan-2015 01:33:33.496 #5 0x10fa3447c in isc_thread_yield()+0xf76835c
> 06-Jan-2015 01:33:33.496 #6 0x10fa34a67 in isc_thread_yield()+0xf768947
> 06-Jan-2015 01:33:33.496 #7 0x10fc1749e in isc_thread_yield()+0xf94b37e
> 06-Jan-2015 01:33:33.496 #8 0x7fff906792fc in
> isc_thread_yield()+0x7ffe903ad1dc
> 06-Jan-2015 01:33:33.496 #9 0x7fff90679279 in
> isc_thread_yield()+0x7ffe903ad159
> 06-Jan-2015 01:33:33.496 #10 0x7fff906774b1 in
> isc_thread_yield()+0x7ffe903ab391
> 06-Jan-2015 01:33:33.496 exiting (due to assertion failure)
> 
> Any suggestions or ideas what caused it and how to prevent in the future?
> 
> Let me know any more info that is required.
> 
> Thanks,
> 
> James.

Normally we'd request that instead of posting a crash here, that you
report it directly at https://www.isc.org/community/report-bug/

To diagnose a named crash problem, we'd be looking for you have saved a
core file from the aborting named process and to be able to submit it
along with the binary that produced the core, the libs on the system
that named was using, and other data:

https://kb.isc.org/article/AA-00340

If you have gdb, then we usually first (before asking you to submit the
files) ask that you load up the core and binary locally (preferably on
the system that produced the crash - then we both know that all the libs
are present and correct versions):

$ <path-to>/gdb <path-to>/named <path-to>/<core>

And then once loaded, issue:

> thread apply all bt full

(Sometimes this doesn't work or terminates prematurely - in which case,
retry without the 'full')

Then we'd want to see the output, from the start of launching gdb (as
the dump loading can also sometimes be useful).

---

However, in this instance, we already have one report of something that
looks very similar (bug reference RT #36888), so we'll contact you
directly off-list to verify.

Cathy