[tor-bugs] #5156 [Obfsproxy]: assertion failure at src/network.c:931: circ
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Thu Mar 1 19:59:04 UTC 2012
#5156: assertion failure at src/network.c:931: circ
-----------------------+----------------------------------------------------
Reporter: arma | Owner: asn
Type: defect | Status: new
Priority: normal | Milestone:
Component: Obfsproxy | Version:
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by nickm):
Replying to [comment:4 asn]:
> Replying to [comment:3 nickm]:
> > Ah, it looks like there's an ordering bug here.
bufferevent_connect_hostname is allowed to complete immediately while it
is called, but the function calling it assumes that it's okay to set up
the ->circuit pointer after the open_outbound_hostname call returns.
> >
> > So the right fix here seems to be setting the circuit earlier, I
guess?
>
> So I see, I didn't know that bufferevent callbacks are triggered
immediately. I thought they were triggered on the next libevent loop;
seems like this is the behavior of deferred callbacks, though.
Most callbacks are; some aren't. Connect/resolve callbacks, especially
failing ones, can happen immediately. (Might be nice to get this fixed in
libevent 2.1)
> So, does `simple_server_listener_cb()` and `simple_client_listener_cb()`
have the same problem? `open_outbound()` seems to do `bufferevent_setcb`
and `bufferevent_socket_connect` before setting up the circuit.
It might on some BSDs. The resolve in bufferevent_connect_hostname seems
to be the main issue with this case, but ISTR that on some BSDs, connect()
can succeed/fail immediately.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5156#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list