Red Hat Bugzilla – Bug 75036
bind 9.2.1-1.7x.2 assertion failure on SMP
Last modified: 2007-04-18 12:47:05 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 Description of problem: bind fails with error: exiting (due to assertion failure) server running kernel 2.4.18-10smp #1 SMP per rhn server has all latest updates server on a private network (no internet access), so DOS is not likely Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. load bind from init script 2. wait for a day 3. sift through rubble Actual Results: named[1698]: task.c:395: REQUIRE((((task) != ((void *)0)) && (((const isc__magic_t*)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K')))))) failed named[1698]: exiting (due to assertion failure) Expected Results: no rubble :o) Additional info: named[1918]: starting BIND 9.2.1 -u named named[1918]: using 2 CPUs named[1921]: loading configuration from '/etc/named.conf' named[1921]: no IPv6 interfaces found named[1921]: listening on IPv4 interface lo, 127.0.0.1#53 named[1921]: listening on IPv4 interface eth0, 192.168.252.224#53
I received the following from ISC in response to a bug report I sent them regarding the very same symptoms: > There is a known race condition in lib/dns/adb.c which can > result in this assertion. The work around is to disable > threads when named is built. > > Note more than one bug may result in the same error message being > produced as the error is actually at a higher level and is only > detected by lower level functions. The only way to determine it > it is the same bug, when the lower level function is called in > multiple places, is to get a stack backtrace.
Check this out in the latest release with new threads package.