Red Hat Bugzilla – Bug 126510
Bind crashes with assertion failure
Last modified: 2007-11-30 17:07:02 EST
Description of problem: Using Bind-9.2.2-21 which is the latest release for ES 3, bind crashed with the following errors: Jun 21 18:05:37 blues1 named[1558]: task.c:395: REQUIRE((((task) != ((void *) 0)) && (((const isc__magic_t *)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K')))))) failed Jun 21 18:05:37 blues1 named[1558]: exiting (due to assertion failure) Additional info: http://bugzilla.conectiva.com/show_bug.cgi?id=10714
This is fixed in bind-9.2.3 which is available from Rawhide or in the next update U3.
When is the scheduled release of Update 3?
Can a hotfix for this issue be provided in the meantime?
This customer still has the problem. He's currently running 9.2.4- EL3_10 and getting the same task.c assertion errors. As a temporary work around, I've added OPTIONS="-n 1" to his /etc/sysconfig/named to disable multi-thread support. After doing so, the customer has yet to report any errors (6 days).
What machine architecture is BIND running on here ? How many CPUs ? Is Hyperthreading enabled ? Please append the result of the command : # cat /proc/cpuinfo run as root on the customer machine to this bug. The latest version of BIND for RHEL-3 is bind-9.2.4-4_EL3 (the final 'release candidate' version of ISC BIND 9.2.4), that will be in the next RHEL-3 update release. Meanwhile, you can download it from: http://people.redhat.com/~jvdias/bind/RHEL-3 Please have the customer try this version and see if it fixes the problem.
Created attachment 108133 [details] Output of cat /proc/cpuinfo
What machine architecture is BIND running on here ? x86 (2.4Ghz P4 Xeon) How many CPUs ? 1 Is Hyperthreading enabled ? yes I'll get the customer to d/l and install the updated bind rpm.
From the /proc/cpuinfo output you attached, it seems like the answer to the question "How many CPUs" should be 2, not one. When bind starts up, it emits a log message like: ' named[$PID]: using 2 CPUs' what does the output of the command: # egrep 'named\[[0-9]+\]:\ using\ [0-9]+\ CPU' | tail -1 say on the customer machine ? By default, BIND 9 now uses 1 CPU unless the '-n' argument is > 1 . To duplicate this problem with BIND-9.2.4-4, please put the line 'OPTIONS=-n2' in /etc/sysconfig/named . How many interfaces does the customer machine have ? If there is more than one interface, does the customer's named.conf specify the option 'query-source address xxx.xxx.xxx.xxx' ? The connectiva 10714 bug mentioned above is now closed, and only happened when the server looked up a domain whose nameservers where incorrectly configured. It would be most helpful, if the problem still occurs for the user, to turn on query logging with: # rndc querylog then the actual query being performed will be written to the log file before the crash message. I'm currently running BIND 9.2.4-4 on a dual P4 processor machine with threads enabled and the '-n2' option, and cannot reproduce this problem.
This problem is not reproducable. It could have been caused by querying nameservers providing bogus data as with the connectiva bug, but does not occur with latest BIND 9 releases. In the absence of further information or reproducibility, closing out.