Verify if GPU message pump is signaled when it hangs in WaitForWork
This is a diagnostic change. The code introduced in this
change runs only when GPU process is about to terminate
with a deliberate crash.
We a getting a number of crashes triggered by GPU hang in
MessagePumpForGpu::WaitForWork. There is already some
instrumentation that indicates that:
a) MessagePumpForGpu::WaitForWork is sitting in
MsgWaitForMultipleObjectsEx for longer than 15 seconds
b) MessagePumpForGpu::ScheduleWork is called after
WaitForWork enters the wait, sometimes several seconds
after, and SetEvent must be called (at least we grab the
timestamp right before calling SetEvent method)
c) The event is set but it doesn't wake up the wait
While it is possible for a thread that is awaken to not
be immediately scheduled by the OS, it is hard to imagine
that going up for 15+ seconds. So the theory is that the
event handle might be recycled and there might be some
other code that has closed but hasn't nulled out the
old handle. Since the event is auto-reset, when there are
multiple waiters only one of them would be awaken and
reset the event, and the other one would
just continue waiting. So if the other code is somehow
still waiting on its closed and now recycled handle, that
would explain the hang.
This code would allow GPU watchdog to check whether
the event was set at the time of the crash. This would
give us a clue of whether the situation described above
is actually happening.
Extra bonus: the investigation would also explain if
Renderer hangs in MessagePumpDefault::Run are caused by
the same issue.
BUG=620904
Review-Url: https://codereview.chromium.org/2077613002
Cr-Commit-Position: refs/heads/master@{#400871}
7 files changed
