On 13 Sep 2008, [EMAIL PROTECTED] wrote:
> I had one headless node running for five days with DHT enabled. It
> had over 300 nodes connected for most of the time period. Rev 15830.
I am not quite capable of solving this one. The DHT lookup seems to
have timed out, but the original lookup has been freed already. If we
do an n-lookup and any of one the lookup succeeds, is the look up
freed and then some latent lookup comes in with a timeout? I think
that is the condition; very tricky.
(gdb) where
#0 0x4034e967 in sigsuspend () from /lib/libc.so.6
#1 0x0815ec30 in crash_handler (signo=6) at crash.c:173
#2 <signal handler called>
#3 0x4034e566 in raise () from /lib/libc.so.6
#4 0x4034fd88 in abort () from /lib/libc.so.6
#5 0x08161e38 in assertion_failure (data=<value optimized out>)
at fast_assert.c:96
#6 0x0814602b in lookup_value_delay (nl=0x421c9aa0) at lookup.c:191
#7 0x08147141 in lookup_value_rpc_cb (type=DHT_RPC_TIMEOUT, kn=0x4173a7c0,
unused_n=0x0, function=0, payload=0x0, len=0, arg=0x408047a8)
at lookup.c:2997
#8 0x08150be0 in rpc_timed_out (unused_cq=0x82dec40, obj=0x41fb8ab8)
at rpc.c:155
#9 0x0815e3a4 in cq_expire (cq=0x82dec40, ev=0x0) at cq.c:446
#10 0x0815e51c in cq_clock (cq=0x82dec40, elapsed=<value optimized out>)
at cq.c:497
#11 0x0815e614 in callout_timer (unused_p=0x0) at cq.c:567
#12 0x400a2a16 in g_source_get_current_time () from /usr/lib/libglib-2.0.so.0
#13 0x400a22f1 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0x400a5983 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#15 0x400a5ea2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#16 0x0811f77a in topless_main_run () at topless.c:49
#17 0x0804e3eb in main (argc=6, argv=0xbfc82614) at main.c:1437
Sorry, I didn't have dht_*_debug flags set.
As an aside, from a cursory glance, it seems that rpc_info and
pmsg_info could be merged and this might simplify things. They have a
circular reference, are always allocated together, and have 'nl' and
lid elements refer to the same thing. Is this due to historic reasons
or is the pmsg intended to persist while the rpc_info is gone during
timeouts or something?
Regards,
Bill Pringlemeir.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
