diff options
| author | shrikant <shrikant@chromium.org> | 2015-04-28 12:35:02 -0700 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2015-04-28 19:35:49 +0000 |
| commit | dfb73a76e24eadbb2311c7b756c0383acefc8f06 (patch) | |
| tree | 8ba5905c29e3c9329d26667d3027b6b9fc485018 /base/win | |
| parent | e6e4db76045d288250869cb81bc92e2cce64ebae (diff) | |
| download | chromium_src-dfb73a76e24eadbb2311c7b756c0383acefc8f06.zip chromium_src-dfb73a76e24eadbb2311c7b756c0383acefc8f06.tar.gz chromium_src-dfb73a76e24eadbb2311c7b756c0383acefc8f06.tar.bz2 | |
Conv CHECK->DCHECK in CloseHandle (top crasher & data enough to debug)
We seem to have gathered enough data to find out debug further cause/reason for calling CloseHandle on already closed/invalid handle.
There are couple of theories which need to be investigated further like policy ownership of TargetProcess and thread watching for JOB_OBJECT_MSG_ACTIVE_PROCESS_ZERO.
CHECK seem to have introduced with CL https://codereview.chromium.org/1045513004
BUG=480639
R=cpu@chromium.org,grt@chromium.org
Review URL: https://codereview.chromium.org/1108953003
Cr-Commit-Position: refs/heads/master@{#327348}
Diffstat (limited to 'base/win')
| -rw-r--r-- | base/win/scoped_handle.cc | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/base/win/scoped_handle.cc b/base/win/scoped_handle.cc index 33a8aa5..034f6a7 100644 --- a/base/win/scoped_handle.cc +++ b/base/win/scoped_handle.cc @@ -40,9 +40,11 @@ typedef base::internal::LockImpl NativeLock; base::LazyInstance<NativeLock>::Leaky g_lock = LAZY_INSTANCE_INITIALIZER; bool CloseHandleWrapper(HANDLE handle) { - if (!::CloseHandle(handle)) - CHECK(false); - return true; + if (::CloseHandle(handle)) + return true; + + NOTREACHED(); + return false; } // Simple automatic locking using a native critical section so it supports |