[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: major | Milestone:
Component: Obfsproxy | Version:
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by 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. 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? Or does the callback approach
prohibit evutil_getaddrinfo_async() from knowing whether it should
return an error?
I uploaded a branch of my current progress in 'bug5156_tmp'.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5156#comment:8>
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