Re: Bug: Expiring a dns resolve that's still pending. Forgot to cull it?

[yancm@xxxxxxxxxxxxxxxx]

I received the following crash info this AM...
From Warning.log
Apr 24 22:08:06.798 [notice] Tor 0.1.0.4-rc opening log file.
Apr 25 00:01:26.395 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 25 00:01:26.395 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 25 00:01:26.395 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 25 00:01:26.395 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 25 00:39:42.072 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 25 00:39:42.073 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 25 00:51:08.710 [err] dns.c:649: connection_dns_process_inbuf:
Assertion buf_datalen(conn->inbuf) == 5 failed; aborting.

Gdb backtrace (bt):
(gdb) bt
#0  0x4821dfeb in kill () from /usr/lib/libc.so.12
#1  0x48292a3f in abort () from /usr/lib/libc.so.12
#2  0x0806c286 in connection_dns_process_inbuf (conn=0x83b0700) at dns.c:668
#3  0x0805bfd4 in connection_handle_read (conn=0x83b0700) at
connection.c:1031
#4  0x0806eba1 in conn_read_callback (fd=73, event=2, _conn=0x83b0700)
    at main.c:354
#5  0x0808d82c in event_process_active ()
#6  0x0808da26 in event_base_loop ()
#7  0x0808d8c4 in event_loop ()
#8  0x0808d84d in event_dispatch ()
#9  0x0806fbc8 in do_main_loop () at main.c:934
#10 0x080705b9 in tor_main (argc=6, argv=0xbfbffba4) at main.c:1573
#11 0x080807a3 in main (argc=6, argv=0xbfbffba4) at tor_main.c:19
#12 0x0804bbb2 in ___start ()
(gdb)





> Hi Roger, Nick, et. al.
>
> This bug is still with me with the new Tor 0.1.0.4-rc
> CVS build.
>
> I managed to update my libevent to 1.0c, but I still get
> a bunch of the messages;
>  Bug: Expiring a dns resolve that's still pending. Forgot to cull it?
> Then after a while (1-10 hours) the process seems to just
> lock up (no longer seems to route traffic), without actually crashing.
>
> I'm running under NetBSD 2.0_Stable...i386
>
> I started a flyspray entry on this bug a few weeks back
> and never heard back from you...
>
> How can I help you track it down?
>
> I can always just turn off the PTHREAD_CREATE switch, but this seems
> to increase resource utilization...I'd like to get this back
> to normal...
>
> Help!
> gene
>
>