On Sat, Sep 29, 2007 at 06:51:51PM -0700, Michael_google gmail_Gersten wrote:
> > Interesting! Is this reproducible?
> Don't know yet.
>
> > Oh! By any chance is your ORListenAddress set in your torrc?
> Nope
>
> > Did you get a core? Was there anything useful in tor.crash.log?
> No core.
> Here's the crash log:
>
>
> Host Name: stbmac
> Date/Time: 2007-09-27 16:24:10.933 -0700
> OS Version: 10.4.10 (Build 8R218)
> Report Version: 4
>
> Command: tor
> Path: /Library/Tor/tor
> Parent: bash [389]
>
> Version: ??? (???)
>
> PID: 23808
> Thread: 0
>
> Exception: EXC_BAD_ACCESS (0x0001)
> Codes: KERN_INVALID_ADDRESS (0x0001) at 0xca5ad9b6
>
> Thread 0 Crashed:
> 0 tor 0x00087c04 event_del + 44 (event.c:697)
> 1 tor 0x0006cdd4 nameserver_up + 84 (eventdns.c:533)
> 2 tor 0x0006cee0 reply_callback + 112 (eventdns.c:648)
> 3 tor 0x0006fc6c reply_handle + 684 (eventdns.c:740)
> 4 tor 0x000714cc nameserver_ready_callback + 1564
> (eventdns.c:925)
> 5 tor 0x00087364 event_process_active + 240 (event.c:332)
> 6 tor 0x00087634 event_base_loop + 340 (event.c:448)
> 7 tor 0x000874cc event_loop + 40 (event.c:382)
> 8 tor 0x000873d0 event_dispatch + 20 (event.c:346)
> 9 tor 0x0004b8b0 tor_main + 656 (main.c:1270)
> 10 tor 0x0000277c _start + 760
> 11 tor 0x00002480 start + 48
Okay. This part is _profoundly_ useful; it says where the crash
happened. It looks like the failing operation is event_del (which is
called as evtimer_del) from eventdns.c around line 533. The function
in question gets called when a name server which we believed was down
gives us a reply anyway. eventdns.c says "oh, wonderful!".. and
deletes the timeout event that was going to tell us to test the
nameserver later on.
But this is after shutting down and restarting ORPort! My guess is
that somewhere along the line we freed or removed the timeout event,
but did not remove the request that's making this code get called.
I'll check this out more tomorrow, once I've gotten a little sleep.
===
Can I take this opportunity to personally thank whoever at Apple
decided that saving a stack trace, in text, for every crash was a good
idea? Thank you! I hope some Linux distribution copies this soon.
>
> Thread 1:
> 0 libSystem.B.dylib 0x90023c60 recvfrom + 12
> 1 tor 0x000350c4 cpuworker_main + 148 (cpuworker.c:254)
> 2 tor 0x0007800c tor_pthread_helper_fn + 76 (compat.c:1016)
> 3 libSystem.B.dylib 0x9002bd08 _pthread_body + 96
This other thread is just being a cpuworker, and waiting for the main
thread to ask it to do something.
yrs,
--
Nick Mathewson
Attachment:
pgpmEROhwfFfP.pgp
Description: PGP signature