crashpad client for 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
new file mode 100644
index 0000000000000000000000000000000000000000..df4abe38c9b9fd9727efa39247768e71f6659c02
--- /dev/null
+++ b/client/crashpad_client_win.cc
@@ -0,0 +1,76 @@
+// Copyright 2014 The Crashpad Authors. All rights reserved.

[scottmg, 2015/04/24 04:55:06]

2015

+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+#include "client/crashpad_client.h"
+
+#include <Windows.h>

[scottmg, 2015/04/24 04:55:06]

lower 'W'

[cpu_(ooo_6.6-7.5), 2015/04/29 01:34:17]

Acknowledged.

+
+namespace {
+// Time to wait for the handler to create a dump. This is tricky to figure out.
+const DWORD kMillisecondsUntilTerminate = 5000;
+
+// These two handles to events are leaked.
+HANDLE g_signal_exception = nullptr;
+HANDLE g_wait_termination = nullptr;
+
+LONG WINAPI UnhandledExceptionHandler(EXCEPTION_POINTERS* exception_pointers) {
+  // TODO (cpu): Here write |exception_pointers| to g_crashpad_info.
+  SignalObjectAndWait(g_signal_exception,

[Mark Mentovai, 2015/04/28 17:53:05]

I would prefer if the return value were checked, so that causes of missing dumps
attributable to errors in this file can be diagnosed.

+                      g_wait_termination,
+                      kMillisecondsUntilTerminate,
+                      FALSE);
+  // We don't want to generate more exceptions, so we take the fast route.
+  TerminateProcess(GetCurrentProcess(), 0);

[Mark Mentovai, 2015/04/28 17:53:05]

0’s probably not the best exit code to use.

+  return 0L;
+}
+
+}  // namespace
+
+namespace crashpad {
+
+CrashpadClient::CrashpadClient() {
+}
+
+CrashpadClient::~CrashpadClient() {
+}
+
+bool CrashpadClient::StartHandler(
+    const base::FilePath& handler,
+    const base::FilePath& database,
+    const std::string& url,
+    const std::map<std::string, std::string>& annotations,
+    const std::vector<std::string>& arguments) {
+  // Unclear if we need to implement this on Windows. We expect that in most
+  // cases SetHandler() is used exclusively.

[Mark Mentovai, 2015/04/28 17:53:05]

This method can still be used to provide the reference implementation. As we
discussed over e-mail or IM last week, the browser might want to StartHandler()
if it finds that SetHandler() (or SetHandler()+UseHandler()) doesn’t work. And
whatever’s responsible for starting the handler at login might wind up calling
into this code too.

I don’t meant that you should implement this right now, just that the comment
doesn’t agree with our discussion, so I’m wondering if the comment predates it
or if things changed after we talked.

[cpu_(ooo_6.6-7.5), 2015/04/29 01:34:17]

Probably my misunderstanding. I'll update the comment.

+  return false;
+}
+
+bool SetHandler(const std::string& ipc_port) {
+  // TODO (cpu): Contact the handler and obtain g_signal_exception and
+  // g_wait_termination.
+  return false;
+}
+
+bool CrashpadClient::UseHandler() {
+  if (!g_signal_exception)
+    return false;
+  if (!g_wait_termination)
+    return false;
+  // In theory we could store the previous handler but it is not clear what
+  // use we have for it.
+  SetUnhandledExceptionFilter(&UnhandledExceptionHandler);
+  return true;
+}
+
+}  // namespace crashpad