aboutsummaryrefslogtreecommitdiff
path: root/src/or/cpuworker.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2015-02-05 12:17:08 -0500
committerNick Mathewson <nickm@torproject.org>2015-02-05 12:17:08 -0500
commit227422155721597d7ad528749f7295e92f1ce9fc (patch)
tree879c2d2027d3f98bdf5da2c81181110b44a6db94 /src/or/cpuworker.c
parent3f993dacc141a105d3e520cf1901dbb635c29ea2 (diff)
downloadtor-227422155721597d7ad528749f7295e92f1ce9fc.tar.gz
tor-227422155721597d7ad528749f7295e92f1ce9fc.zip
Fix a work-counting bug introduced by the workqueue merge
David Goulet finds that when he runs a busy relay for a while with the latest version of the git code, the number of onionskins handled slowly dwindles to zero, with total_pending_tasks wedged at its maximum value. I conjecture this is because the total_pending_tasks variable isn't decremented when we successfully cancel a job. Fixed that. Fixes bug 14741; bugfix not on any released version of tor.
Diffstat (limited to 'src/or/cpuworker.c')
-rw-r--r--src/or/cpuworker.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/src/or/cpuworker.c b/src/or/cpuworker.c
index 3ddb37a262..5e8b32d780 100644
--- a/src/or/cpuworker.c
+++ b/src/or/cpuworker.c
@@ -298,6 +298,7 @@ cpuworker_onion_handshake_replyfn(void *work_)
cpuworker_reply_t rpl;
or_circuit_t *circ = NULL;
+ tor_assert(total_pending_tasks > 0);
--total_pending_tasks;
/* Could avoid this, but doesn't matter. */
@@ -553,6 +554,8 @@ cpuworker_cancel_circ_handshake(or_circuit_t *circ)
/* It successfully cancelled. */
memwipe(job, 0xe0, sizeof(*job));
tor_free(job);
+ tor_assert(total_pending_tasks > 0);
+ --total_pending_tasks;
}
circ->workqueue_entry = NULL;