bind-9.4.0b2 exits unexpected...

[JINMEI Tatuya / 神明達哉]

>>>>> On Mon, 09 Oct 2006 10:16:21 +0200, 
>>>>> Marco Schumann <schumann at strato-rz.de> said:

>>> 07-Oct-2006 21:03:29.393 general: rbtdb.c:1158: REQUIRE(prev > 0) failed
>>> 07-Oct-2006 21:03:29.393 general: exiting (due to assertion failure)
>>> ...
>>> 08-Oct-2006 19:32:31.666 general: rbtdb.c:1158: REQUIRE(prev > 0) failed
>>> 08-Oct-2006 19:32:31.666 general: exiting (due to assertion failure)
>>> ...
>> 
>>> What happens exactly? isc_refcount_decrement returns NULL when... when?
>>> And why is it so fatal, that the whole process must die? Was this
>>> introduced in this version? In bind-9.3.2-P1 the macro was called only
>>> once in that file, bind-9.4.0b2 executes it 7 times. Does this behaviour
>>> correlate with the number of worker threads as it seems to be a locking
>>> issue? And if so, which way?
>> 
>> Did named dump core?  If so, showing its backtrace would be helpful.

> Here it is (I hope this is what you expected):

Yes, it is.  Thanks.  Can you also get backtrace of other thread(s)
than the one triggered the assertion failure?  Normally you should be
able to do that as follows:

(gdb) info threads
  7 Thread 1086323040 (LWP 23365)  [...]
  6 Thread 1084225888 (LWP 23364)  [...]
  5 Thread 1082128736 (LWP 23363)  [...]
* 4 Thread 1080031584 (LWP 23362)  [...]
  3 Thread 1077934432 (LWP 23361)  [...]
  2 Thread 1075837280 (LWP 23360)  [...]
  1 Thread 182899679392 (LWP 23342)  [...]
(output details may vary among OS/gdb version, etc)

Then thread #4 (marked with `*') should probably be the triggering
thread.  To see backtrace of, say, thread #3, we do as follows:

(gdb) thr 3
[Switching to thread 3 (Thread 1077934432 (LWP 23361))]#0  [...]

(gdb) bt

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp