Re: [tor-bugs] #5156 [Obfsproxy]: assertion failure at src/network.c:931: circ

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5156: assertion failure at src/network.c:931: circ
-----------------------+----------------------------------------------------
 Reporter:  arma       |          Owner:  asn
     Type:  defect     |         Status:  new
 Priority:  major      |      Milestone:     
Component:  Obfsproxy  |        Version:     
 Keywords:             |         Parent:     
   Points:             |   Actualpoints:     
-----------------------+----------------------------------------------------

Comment(by nickm):

 Replying to [comment:8 asn]:
 > I'd like some help:
 >
 https://gitweb.torproject.org/obfsproxy.git/blob/HEAD:/src/network.c#l613
 >
 > It seems like that if the arguments to
 > `bufferevent_socket_connect_hostname()` are well-formed, the function
 > will always return 0.

 I believe that's right.

 > This means that if the DNS lookup fail, it will
 > go into `pending_socks_cb()` (since the callbacks were set before the
 > connect_hostname() call), then into `error_or_eof()`, then it will
 > free the whole circuit, and then it will continue happily to line623
 > which is `bufferevent_enable(buf, EV_READ|EV_WRITE);`.  that causes a
 > segfault.  I'm encountering this problem while trying to solve
 > #5156. We currently don't have this problem because we assert out in
 > `pending_socks_cb()`.

 >
 > So the question is, how should we avoid continuing if
 > `bufferevent_socket_connect_hostname()` fails immediately?  Or maybe
 > this is not the correct question to ask?
 >
 > Also, is this a bug of libevent?

 It confuses enough people that it should probably change, but it's not
 actually a bug: it's working, and working as documented.

 >  Or does the callback approach
 > prohibit evutil_getaddrinfo_async() from knowing whether it should
 > return an error?

 Generally the callback model means that we launch an operation, and if we
 launch it successfully, we say "yay, success!" even if the operation
 itself will fail.

 > I uploaded a branch of my current progress in 'bug5156_tmp'.

 Replying to [comment:9 asn]:
 > Trying to answer my above question; would moving the
 bufferevent_enable() and bufferevent_disable() commands before the
 bufferevent_socket_conect_hostname() be a sufficient countermeasure?

 Should work!

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5156#comment:10>
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