>>>>> On Mon, 09 Oct 2006 10:16:21 +0200,
>>>>> Marco Schumann 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@isl.rdc.toshiba.co.jp