[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5156 [Obfsproxy]: assertion failure at src/network.c:931: circ
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs