Implement more of CrashpadClient on Windows

client/crashpad_client_win.cc

Index: client/crashpad_client_win.cc
diff --git a/client/crashpad_client_win.cc b/client/crashpad_client_win.cc
index 734bedfd84301af5cf81162fe1723d21ba43240e..da04fce199b49adc4afd35dddec2c5f83582fb04 100644
--- a/client/crashpad_client_win.cc
+++ b/client/crashpad_client_win.cc
@@ -16,14 +16,21 @@
 
 #include <windows.h>
 
+#include "base/atomicops.h"
 #include "base/logging.h"
+#include "base/strings/string16.h"
+#include "base/strings/utf_string_conversions.h"
+#include "client/crashpad_info.h"
+#include "client/registration_protocol_win.h"
+#include "util/file/file_io.h"
+#include "util/win/scoped_handle.h"
 
 namespace {
 // Time to wait for the handler to create a dump. This is tricky to figure out.
 const DWORD kMillisecondsUntilTerminate = 5000;
 
 // This is the exit code that the process will return to the system once the
-// crash has been handled by Crashpad. We don't want to clash with the 
+// crash has been handled by Crashpad. We don't want to clash with the
 // application-defined exit codes but we don't know them so we use one that is
 // unlikely to be used.
 const UINT kCrashExitCode = 0xffff7001;
@@ -32,8 +39,30 @@ const UINT kCrashExitCode = 0xffff7001;
 HANDLE g_signal_exception = nullptr;
 HANDLE g_wait_termination = nullptr;
 
+// Tracks whether a thread has already entered UnhandledExceptionHandler.
+base::subtle::AtomicWord g_have_crashed;
+
 LONG WINAPI UnhandledExceptionHandler(EXCEPTION_POINTERS* exception_pointers) {
-  // TODO (cpu): Here write |exception_pointers| to g_crashpad_info.
+  // This is a per-process handler. While this handler is being invoked, other
+  // threads are still executing as usual, so multiple threads could enter at
+  // the same time. Because we're in a crashing state, we shouldn't be doing
+  // anything that might cause allocations, call into kernel mode, etc. So, we
+  // don't want to take a critical section here to avoid simultaneous access to
+  // the global exception pointers in CrashpadInfo. Because the crash handler
+  // will record all threads, it's fine to simply have the second and subsequent
+  // entrants block here. They will soon be suspended by the crash handler, and
+  // then the entire process will be terminated below. This means that we won't
+  // the exception pointers from the second and further crashes, but contention

[Mark Mentovai, 2015/08/14 14:20:54]

Missing a word.

[scottmg, 2015/08/14 21:13:21]

Done.

+  // here is very unlikely, and we'll still have a stack that's blocked at this
+  // location.

[cpu_(ooo_6.6-7.5), 2015/08/14 00:47:13]

yeah, it would be nice to know the count of threads that tried to enter after
the first one but blocking is the right call imho.

[scottmg, 2015/08/14 21:13:21]

We could alias the count to the stack, but since it should be very uncommon
anyway, I think I won't bother adding the clutter for now.

+  if (base::subtle::Barrier_AtomicIncrement(&g_have_crashed, 1) > 1) {
+    SleepEx(false, INFINITE);
+  }
+
+  // Otherwise, we're the first thread, so record the exception pointer and
+  // signal the crash handler.
+  crashpad::CrashpadInfo::GetCrashpadInfo()->set_exception_pointers(
+      exception_pointers);
   DWORD rv = SignalObjectAndWait(g_signal_exception,
                                  g_wait_termination,
                                  kMillisecondsUntilTerminate,
@@ -51,6 +80,39 @@ LONG WINAPI UnhandledExceptionHandler(EXCEPTION_POINTERS* exception_pointers) {
   return 0L;
 }
 
+// Returns a pipe handle connected to the RegistrationServer.
+crashpad::ScopedFileHANDLE Connect(const base::string16& pipe_name) {
+  crashpad::ScopedFileHANDLE pipe;
+  const int kMaxTries = 5;
+  for (int tries = 0; !pipe.is_valid() && tries < kMaxTries; ++tries) {
+    if (!WaitNamedPipe(pipe_name.c_str(), NMPWAIT_WAIT_FOREVER)) {
+      PLOG(ERROR) << "WaitNamedPipe";

[cpu_(ooo_6.6-7.5), 2015/08/14 00:47:13]

WaitNamedPipe internally tries to open the NPFS device, so it is a bit slow and
beholden to AV crazies. The recommended way is to try to Open first and if that
fails then wait on it.

I am not sure if infinite timeout is the right amount, sort of makes hosedness
of the crash service manifest into hosedness of chrome but we can start there. I
am guessing at some point we want to error out after some time, maybe in the
minutes. I mean as long we can get telemetry back to us of this case. If we
don't have telemetry back to us then infinite is better.

[scottmg, 2015/08/14 21:13:21]

Thanks, switched to a 60s timeout and tried opening before waiting.
Telemetry-wise, we don't have anything in Crashpad, but we plan to gather the
LOG()s eventually so that would let us discover this case.

+    }
+    pipe.reset(CreateFile(pipe_name.c_str(),

[Mark Mentovai, 2015/08/14 14:20:54]

So regardless of whether WaitNamedPipe() succeeds, you proceed to the
CreateFile()?

[scottmg, 2015/08/14 21:13:21]

Done.

+                          GENERIC_READ | GENERIC_WRITE,
+                          0,
+                          nullptr,
+                          OPEN_EXISTING,
+                          SECURITY_SQOS_PRESENT | SECURITY_ANONYMOUS,
+                          nullptr));
+    if (!pipe.is_valid()) {
+      PLOG(ERROR) << "CreateFile pipe connection";
+    } else {
+      DWORD mode = PIPE_READMODE_MESSAGE;
+      if (!SetNamedPipeHandleState(pipe.get(),
+                                   &mode,
+                                   nullptr,  // Don't set maximum bytes.
+                                   nullptr)) {  // Don't set maximum time.
+        PLOG(ERROR) << "SetNamedPipeHandleState";
+        pipe.reset();
+      }
+    }
+  }
+  if (!pipe.is_valid())
+    return crashpad::ScopedFileHANDLE();
+  return pipe.Pass();
+}
+
 }  // namespace
 
 namespace crashpad {
@@ -67,14 +129,30 @@ bool CrashpadClient::StartHandler(
     const std::string& url,
     const std::map<std::string, std::string>& annotations,
     const std::vector<std::string>& arguments) {
-  // TODO(cpu): Provide a reference implementation.
   return false;
 }
 
 bool CrashpadClient::SetHandler(const std::string& ipc_port) {
-  // TODO (cpu): Contact the handler and obtain g_signal_exception and
-  // g_wait_termination.
-  return false;
+  RegistrationRequest request = {0};
+  request.client_process_id = GetCurrentProcessId();
+  request.crashpad_info_address =
+      reinterpret_cast<WinVMAddress>(CrashpadInfo::GetCrashpadInfo());
+
+  RegistrationResponse response = {0};
+
+  ScopedFileHANDLE pipe = Connect(base::UTF8ToUTF16(ipc_port));
+  if (!pipe.is_valid())
+    return false;
+  bool result = LoggingWriteFile(pipe.get(), &request, sizeof(request)) &&
+                LoggingReadFile(pipe.get(), &response, sizeof(response));

[cpu_(ooo_6.6-7.5), 2015/08/14 00:47:13]

TransactNamedPipe is available if you want to, but I am fine with write + read. 
Just sayin'

[scottmg, 2015/08/14 21:13:21]

I think I'll stick with Write+Read since it has logging already.

+  if (!result)
+    return result;
+
+  // The server returns these already duplicated to be valid in this process.
+  g_signal_exception = reinterpret_cast<HANDLE>(response.request_report_event);
+  g_wait_termination =
+      reinterpret_cast<HANDLE>(response.report_complete_event);
+  return true;
 }
 
 bool CrashpadClient::UseHandler() {