bug in address family checking?

[Nick Mathewson]

On Mon, Dec 22, 2008 at 04:45:34PM -0800, coderman wrote:
> xiando was discussing strange messages in the log of the form:
> [warn] tor_addr_is_null(): Bug: Called with unknown address family XXX
> 
> where XXX is some unexpected value.
> 
> in tracing this down, it always appears after
> connection_exit_begin_conn() when the DNS resolve returns immediately
> (cached name) and connection_exit_connect() is invoked.
> 
> based on the order of calls, it appears that connection_init() is
> setting conn->socket_family but is not setting conn->addr.family
> (which is what tor_addr_is_null() is looking for).
> 
> attached is a very simply patch to set both in connection_init().
> however, i do not know enough about Tor internals or the nature of the
> IPv6 changes to know if this is the right fix, or if some other cause
> is at fault.

This shouldn't be necessary.  First off, you shouldn't need to
manipulate an tor_addr_t's internals directly.  Second, everything
that calls connection_init() passes it a chunk of RAM that it got from
tor_malloc_zero, which should also zero out connection->addr, which
should result in it having addr_family 0, not addr_family 20 (which is
what the user was seeing on IRC).  Right?

If this is happening on a edge_connection after it finds a cached dns
answer, then the addr field has already been changed from its original
value. Check out the code in dns.c around line 688.

To debug this thing, the easiest solution  is probably to use gdb to
a stack trace for when the warning message is triggered, to sew where
exactly it's happening in the code.

-- 
Nick