JINMEI Tatuya / 神明達哉 schrieb:
>>>>>> 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


Hello,

here the backtrace:

(gdb) info threads
19 process 20942 0xffffe410 in __kernel_vsyscall ()
18 process 20943 0xffffe410 in __kernel_vsyscall ()
17 process 20944 0xffffe410 in __kernel_vsyscall ()
16 process 20945 0xffffe410 in __kernel_vsyscall ()
15 process 20947 0xb7e09506 in fetch_name (adbname=0xb5a5b038,
start_at_zone=, type=0) at adb.c:3336
14 process 20948 0xffffe410 in __kernel_vsyscall ()
13 process 20949 0xffffe410 in __kernel_vsyscall ()
12 process 20950 0xffffe410 in __kernel_vsyscall ()
11 process 20951 0xffffe410 in __kernel_vsyscall ()
10 process 20952 0xffffe410 in __kernel_vsyscall ()
9 process 20953 0xffffe410 in __kernel_vsyscall ()
8 process 20954 0xffffe410 in __kernel_vsyscall ()
7 process 20955 0xffffe410 in __kernel_vsyscall ()
6 process 20956 0xffffe410 in __kernel_vsyscall ()
5 process 20957 0xffffe410 in __kernel_vsyscall ()
4 process 20958 0xffffe410 in __kernel_vsyscall ()
3 process 20959 0xffffe410 in __kernel_vsyscall ()
2 process 20960 0xffffe410 in __kernel_vsyscall ()
* 1 process 20946 0xffffe410 in __kernel_vsyscall ()
(gdb) thr 1
[Switching to thread 1 (process 20946)]#0 0xffffe410 in
__kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7b397d0 in raise () from /lib/libc.so.6
#2 0xb7b3aea3 in abort () from /lib/libc.so.6
#3 0x08064b42 in assertion_failed (file=0xb7f01a11 "ortlistp != ((void
*)0) && *portlistp == ((void *)0)", line=1158,
type=isc_assertiontype_require, cond=0xb7ef3e45
"\004$\213\203��$\b") at ./main.c:159
#4 0xb7e4c918 in cache_zonecut_callback (node=0x0, name=0x0, arg=0x0)
at rbtdb.c:2964
#5 0xb7e55367 in free_rbtdb (rbtdb=0x0, log=3086031024, event=0x3b7) at
rbtdb.c:609
#6 0xb7e556e1 in free_rbtdb (rbtdb=0x0, log=isc_boolean_false,
event=0x0) at rbtdb.c:640
#7 0xb7e970ac in compare_hs_a (rdata1=0xa6ef887c, rdata2=0x89e821e8) at
../rdata/hs_4/a_1.c:122
#8 0xb7ea0444 in dns_resolver_getlamettl (resolver=0x8260fa4) at
resolver.c:6774
#9 0xb7ead4b4 in resquery_response (task=0xaea49278, event=0xa6ef8840)
at resolver.c:4103
#10 0xb7c7fe12 in run (uap=0xb7a630b0) at task.c:867
#11 0xb7c3634b in start_thread () from /lib/libpthread.so.0
#12 0xb7bce65e in clone () from /lib/libc.so.6

I am really interested in what I can learn from that, thanks for your
help so far.

Kind regards
--
_____________________________
[Marco Schumann