| commit | 95238eb9174f0cfee9d313ce15b4f9b471f3d0e5 | |
| author | Nick Mathewson <nickm@torproject.org> | |
| Thu, 16 Nov 2017 16:45:15 +0000 (16 11:45 -0500) | ||
| committer | Nick Mathewson <nickm@torproject.org> | |
| Thu, 16 Nov 2017 17:05:56 +0000 (16 12:05 -0500) | ||
| tree | f314bbf8f6366c0f911c295de4cd36aa3269c415 | treesnapshot (tar.gz zip) |
| parent | 6f8c32b7deb9f0cec6d1553aba71969c9fb6064f | commitdiff |
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.
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.
| changes/bug24167 | [new file with mode: 0644] | blob |
| src/or/connection.c | diffblobblamehistory |