[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Tor 0.0.9.1 crashed
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Tor 0.0.9.1 crashed
- From: Roger Dingledine <arma@xxxxxxx>
- Date: Mon, 3 Jan 2005 22:26:42 -0500
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivery-date: Mon, 03 Jan 2005 22:27:04 -0500
- In-reply-to: <41D4FA75.email@example.com>; from firstname.lastname@example.org on Fri, Dec 31, 2004 at 09:06:29AM +0200
- References: <41D4087F.email@example.com> <41D4FA75.firstname.lastname@example.org>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Mutt/220.127.116.11i
On Fri, Dec 31, 2004 at 09:06:29AM +0200, Giorgos Pallas wrote:
> Today, the server crashed again. Again, the error message seems to have
> to do with dns, but is another from yesterday's error.
> Dec 31 07:50:01.038 [err] dns.c:399: dns_cancel_pending_resolve:
> Assertion resolve->pending_connections failed; aborting.
This could be triggered from any number of situations, and it will be
really hard to track down without more information.
Do you have a core file for us, or a back-trace from gdb or something?
If not, can you ulimit -c unlimited so you have one for next time?
What platform are you running on? Are you sure the version was 0.0.9.1?
Can you trigger this behavior? If not, how often does it occur by chance?
Do you have any debug-level logs, by any chance? Can you make some for
us and try to trigger the behavior again?
> > Dec 30 15:40:57.489 [warn] fetch_from_buf_socks(): Socks version 19 not
> > recognized. (Tor is not an http proxy.)
> > Dec 30 15:40:57.511 [warn] connection_ap_handshake_process_socks():
> > Fetching socks handshake failed. Closing.
What are you doing to your Tor socksport to cause this warning
repeatedly? You (or somebody) is connecting to it with some application
that is speaking a protocol other than socks.
> > Dec 30 15:46:29.338 [warn] connection_dns_reached_eof(): Read eof.
> > Worker died unexpectedly.
This is weird. Dns workers are extra processes we spawn to call
gethostbyname() (that is, do dns resolves), since that function waits to
return until it has its answer, so we can't run it in the main process.
But typically they don't just die for no reason. Are you killing processes
randomly on your machine? :) Are you nearly out of memory? Hm.
I could fix your immediate problem for now by making
dns_cancel_pending_resolve() just return immediately if
!resolve->pending_connections -- but this will mean we'll never find
the bug. :)