freebsd stable - Jul 2005 - 5.4-p3 and bind9: isc_mutex_init failed in new_adbfind / exited on signal 11

Hi,

after upgrading to 5.4-p3 I have problems with bind 9. After a few
days it exits on signal 11. I am using an SMP kernel.  I have found
some other people describing the same problem, without a solution. 
On 5.3 I did not experience such things, bind runs stable.  Just
want to confirm this issue to whom it may concern.

If someone needs more info to debug or have hints/workarounds,
please answer.

named[721]: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/adb.c:1439:
unexpected error:
named[721]: isc_mutex_init failed in new_adbfind()
pid 721 (named), uid 53: exited on signal 11

bye,
Andy

> Hi,
> 
> after upgrading to 5.4-p3 I have problems with bind 9. After a few
> days it exits on signal 11. I am using an SMP kernel.  I have found
> some other people describing the same problem, without a solution. 
> On 5.3 I did not experience such things, bind runs stable.  Just
> want to confirm this issue to whom it may concern.
> 
> If someone needs more info to debug or have hints/workarounds,
> please answer.
> 
> named[721]:
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/adb.c:1439:
> unexpected error:
> named[721]: isc_mutex_init failed in new_adbfind()
> pid 721 (named), uid 53: exited on signal 11
> 
> bye,
> Andy
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
	FreeBSD's pthread_mutex_init() (isc_mutext_init()) can fail
	if there is no memory.  On most other OS this is not the case.
	
	The callers to isc_mutext_init() assume that a failure is due
	to a double initialision and as a result log a error message
	when it fails.  Memory allocation failures on the other hand
	are not logged.

	What I suspect is happening here is that you are seeing a
	error in the error path due to a memory allocation failure
	which results in a NULL pointer de-reference.  A stack
	backtrace from the core dump would pinpoint the error
	location.  To get this you really need named to have been
	built w/ -g and set kern.sugid_coredump=1.
	
	You can avoid the issue by tuning named so that it doesn't run
	out of memory.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org