diff options
author | jar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-11-25 22:30:23 +0000 |
---|---|---|
committer | jar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-11-25 22:30:23 +0000 |
commit | 7ee2fe8a42102269b37467f3072b63065d6a850d (patch) | |
tree | fd33e1cd3bad1c89920bd39c73eae6f123639bfc /tools/memory_watcher | |
parent | 4091a1b6c069d02a08ff1e93dd3effec8f33b6d3 (diff) | |
download | chromium_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.h | 2 |
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(); } |