summaryrefslogtreecommitdiff
path: root/changes
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2017-11-16 11:45:15 -0500
committerNick Mathewson <nickm@torproject.org>2017-11-16 12:05:56 -0500
commit95238eb9174f0cfee9d313ce15b4f9b471f3d0e5 (patch)
treef314bbf8f6366c0f911c295de4cd36aa3269c415 /changes
parent6f8c32b7deb9f0cec6d1553aba71969c9fb6064f (diff)
downloadtor-95238eb9174f0cfee9d313ce15b4f9b471f3d0e5.tar.gz
tor-95238eb9174f0cfee9d313ce15b4f9b471f3d0e5.zip
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 89d422914a0c3cb, I believe, which appeared in Tor 0.1.0.1-rc.
Diffstat (limited to 'changes')
-rw-r--r--changes/bug241677
1 files changed, 7 insertions, 0 deletions
diff --git a/changes/bug24167 b/changes/bug24167
new file mode 100644
index 0000000000..fd0d87efff
--- /dev/null
+++ b/changes/bug24167
@@ -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.
+