summaryrefslogtreecommitdiffstats
path: root/tools/memory_watcher
diff options
context:
space:
mode:
authorjar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-25 22:30:23 +0000
committerjar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-25 22:30:23 +0000
commit7ee2fe8a42102269b37467f3072b63065d6a850d (patch)
treefd33e1cd3bad1c89920bd39c73eae6f123639bfc /tools/memory_watcher
parent4091a1b6c069d02a08ff1e93dd3effec8f33b6d3 (diff)
downloadchromium_src-7ee2fe8a42102269b37467f3072b63065d6a850d.zip
chromium_src-7ee2fe8a42102269b37467f3072b63065d6a850d.tar.gz
chromium_src-7ee2fe8a42102269b37467f3072b63065d6a850d.tar.bz2
Fix typo in recursion detection logic
When releasing the lock, I incorrectly set the thread owner for the lock to the current thread, rather than resetting it to zero. The result is that some number of stacks were not being recorded into the stack map (because the recursion blocking logic aborted the attempt to gather the lock). If I ever do a recursive acquisition (i.e., my logic is faulty), then an assertion will fire in the Acquire() for the lock. This in turn guarantees that when I Release() the lock, it was not a (windows allowed) recursive acquisition of the lock, and hence the thread owning the lock should indeed be zeroed. r=mbelshe Review URL: http://codereview.chromium.org/443009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33140 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'tools/memory_watcher')
-rw-r--r--tools/memory_watcher/call_stack.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/tools/memory_watcher/call_stack.h b/tools/memory_watcher/call_stack.h
index 2c026bc..aa3685d 100644
--- a/tools/memory_watcher/call_stack.h
+++ b/tools/memory_watcher/call_stack.h
@@ -84,7 +84,7 @@ class CallStack {
}
static void UnlockDbgHelp() {
- active_thread_id_ = GetCurrentThreadId();
+ active_thread_id_ = 0;
dbghelp_lock_.Release();
}