Dump process type into breakpad.

components/crash/content/app/breakpad_linux.cc

Index: components/crash/content/app/breakpad_linux.cc
diff --git a/components/crash/content/app/breakpad_linux.cc b/components/crash/content/app/breakpad_linux.cc
index 30ae96b6878cb7e7f1158761a5055e10bcc58fd8..ef9a5b5d527ce7315115745576190be33930a878 100644
--- a/components/crash/content/app/breakpad_linux.cc
+++ b/components/crash/content/app/breakpad_linux.cc
@@ -101,7 +101,7 @@ ExceptionHandler* g_breakpad = nullptr;
 const char* g_asan_report_str = nullptr;
 #endif
 #if defined(OS_ANDROID)
-const char kWebViewProcessType[] = "webview";
+const char kWebViewSingleProcessType[] = "webview-singleprocess";

[hush (inactive), 2016/06/22 21:34:19]

I hope this change does not break anything that tries to strictly match
"webview" (like somewhere in the server side?)

[Torne, 2016/06/23 13:40:10]

Since we don't upload the string currently I don't think this can break anything
on the server side.

I'm not sure "webview-singleprocess" is a good string here, though. It seems
like it would make more sense to either:
1) have *all* the webview process types identify that they're webview,  for the
avoidance of doubt, or
2) have the string just be "singleprocess" or "single" or similar, and *also*
use it for chrome if chrome is running with kSingleProcess set (and then
possibly also change minidumps similarly)?

I'd lean toward 2.. what do you think?

[hush (inactive), 2016/06/23 19:13:14]

Does chrome actually run in single process mode in any production distribution?
I'm just not sure what the benefit is. It seems to be doing #1 is enough (and
easiest, least amount of work)

[hush (inactive), 2016/06/24 20:18:46]

Anyway... I went with #1 in the next patch set. Let me know if you have any
problems..

 char* g_process_type = nullptr;
 ExceptionHandler* g_microdump = nullptr;
 int g_signal_code_pipe_fd = -1;
@@ -137,6 +137,7 @@ class MicrodumpInfo {
   const char* microdump_build_fingerprint_;
   const char* microdump_product_info_;
   const char* microdump_gpu_fingerprint_;
+  const char* microdump_process_type_;
 };
 
 base::LazyInstance<MicrodumpInfo> g_microdump_info =
@@ -883,7 +884,7 @@ void MicrodumpInfo::Initialize(const std::string& process_type,
   DCHECK(thread_checker_.CalledOnValidThread());
   DCHECK(!g_microdump);
   bool is_browser_process =
-      process_type.empty() || process_type == kWebViewProcessType;
+      process_type.empty() || process_type == kWebViewSingleProcessType;
 
   MinidumpDescriptor descriptor(MinidumpDescriptor::kMicrodumpOnConsole);
 
@@ -894,6 +895,13 @@ void MicrodumpInfo::Initialize(const std::string& process_type,
     descriptor.microdump_extra_info()->product_info = microdump_product_info_;
   }
 
+  // MicroDumpExtraInfo::process_type will have 3 possible values:
+  // webview-singleprocess, browser, renderer
+  microdump_process_type_ =
+      strdup(process_type.empty() ? "browser" : process_type.c_str());
+  ANNOTATE_LEAKING_OBJECT_PTR(microdump_process_type_);
+  descriptor.microdump_extra_info()->process_type = microdump_process_type_;
+
   if (android_build_fp) {
     microdump_build_fingerprint_ = strdup(android_build_fp);
     ANNOTATE_LEAKING_OBJECT_PTR(microdump_build_fingerprint_);
@@ -912,7 +920,7 @@ void MicrodumpInfo::Initialize(const std::string& process_type,
                            true,  // Install handlers.
                            -1);   // Server file descriptor. -1 for in-process.
 
-  if (process_type == kWebViewProcessType) {
+  if (process_type == kWebViewSingleProcessType) {

[Torne, 2016/06/23 13:40:10]

There's a problem here, which is not introduced by your change (it's already
wrong), but we should probably address it - I'm fairly sure that the special
handling of DumpWithoutCrashing needs to *always* be applied to WebView, not
just when it's running in single-process mode, which is currently what happens
here. You might want to check with Toby about this. If that's the case, then we
can't rely on process_type to know whether to do something special for webview
and would need to configure this in some other way.

[hush (inactive), 2016/06/23 19:13:14]

Added Toby to the CL.
Toby, should SetDumpWithoutCrashingFunction be always called for webview instead
of singleprocess webview only?

[Tobias Sargeant, 2016/06/24 15:39:08]

We should definitely set this for both single and multiprocess webview. At the
moment GSA really only care about getting minidumps on demand from the browser
process, so although we need to work out what to do for the renderer at some
point, doing this in single process and multiprocess-browser should be enough.

[hush (inactive), 2016/06/24 20:18:46]

All right. I uploaded new patch set with a todo in your name for the renderer
process.

     // We do not use |DumpProcess()| for handling programatically
     // generated dumps for WebView because we only know the file
     // descriptor to which we are dumping at the time of the call to