Fix a traceback when closing a blocked connection "immediately".

When we close a connection via connection_close_immediately, we kill
its events immediately. But if it had been blocked on bandwidth
read/write, we could try to re-add its (nonexistent) events later
from connection_bucket_refill -- if we got to that callback before
we swept the marked connections.

Fixes bug 24167.  Fortunately, this hasn't been a crash bug since we
introduced connection_check_event in 0.2.9.10, and backported it.

This is a bugfix on commit 89d422914a, I believe, which
appeared in Tor 0.1.0.1-rc.
This commit is contained in:
Nick Mathewson 2017-11-16 11:45:15 -05:00
parent 6f8c32b7de
commit 95238eb917
2 changed files with 11 additions and 0 deletions

7
changes/bug24167 Normal file
View File

@ -0,0 +1,7 @@
o Minor bugfixes (network layer):
- When closing a connection via close_connection_immediately(), we
mark it as "not blocked on bandwidth", to prevent later calls
from trying to unblock it, and give it permission to read. This
fixes a backtrace warning that can happen on relays under various
circumstances. Fixes bug 24167; bugfix on 0.1.0.1-rc.

View File

@ -721,6 +721,10 @@ connection_close_immediate(connection_t *conn)
connection_unregister_events(conn);
/* Prevent the event from getting unblocked. */
conn->read_blocked_on_bw =
conn->write_blocked_on_bw = 0;
if (SOCKET_OK(conn->s))
tor_close_socket(conn->s);
conn->s = TOR_INVALID_SOCKET;