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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users