Proposal, from discussion with Toby:

1) When the renderer crashes, have the breakpad handler emit the microdump to the browser process (through a pipe, or a shared fd, or something - similar to how minidumps work) instead of to logcat. Then, terminate the process abruptly with _exit() instead of invoking the system crash handler. This will suppress the first system crash dialog (with "Android System WebView").

2) When the browser detects the renderer's death, read the microdump from the pipe/file/whatever, emit it to the log, and set a flag to disable printing a microdump in breakpad. Then, call abort() to crash the browser intentionally, as we do now. The only microdump in the log will now be the renderer crash, and we'll proceed to the system crash handler as normal, showing the crash dialog with the app's name in it.

Advantages:
- Just one dialog
- Dialog still associated with app, so feedback will be visible to app developer
- Only one dump in the log so no confusion over which one to process

Disadvantages:
- Feedback metadata (like debuggerd backtrace) will always be for the browser crash, but this information is not very important when there's a microdump, and it will always be wrong in the "same way" so it should be easy to disregard.

What do you think?

the "set a flag" thing, what if it gets accidentally set by memory corruption or something like that..?

I guess we could check for a specific bit pattern to make it less likely than "if (foo)"

Probably not much more likely than any of the other ways that crash reporting can already fail (like being out of virtual address space).

We could be paranoid about it, though, yes. Only pay attention if it's an abort() and not a segfault, magic bit pattern, etc.

I think we can disable the microdump on if(signum==SIGQUIT && suppress_microdump) - so the worst that could happen is that we miss a microdump in the case where the browser process has decided to abort for some reason other than a renderer crash, but memory corruption has flipped the flag.

s/SIGQUIT/SIGABRT/, as Torne points out.

The renderer crash will be attributed to Chrome if monochrome happens to be the webview provider, which is going to be more confusing for the user.

By the way, how is the magic bit pattern more resistant to memory corruption than a single bit?

Bo means having the condition check look like "if (skipMicrodump == 0x62adf345)" or similar, instead of just testing for it being true. This would mean that a memory corruption would have to overwrite this variable with this specific arbitrary value, instead of just any nonzero value, or 1.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fa882b53462e83fd7a2470f375ee322f7c9c8914

commit fa882b53462e83fd7a2470f375ee322f7c9c8914
Author: tobiasjs <tobiasjs@chromium.org>
Date: Tue Jan 17 20:42:40 2017

Suppress browser microdump when renderer crashes in multiprocess WebView.

Currently when WebView is in multiprocess mode and the renderer crashes,
browser code detects the crash and terminates the application in order
to provide compatibility with single process behaviour (where a renderer
crash would implicitly also be an application crash). We need the browser
(= application process) to die in a way that triggers debuggerd, but we
don't want the browser microdump (it's not informative). For this reason,
we suppress the generation of the microdump at the point we terminate
the application.

The renderer process crash dialog is already suppressed on user builds,
by virtue of not re-raising the signal.

BUG= 642344 

Review-Url: https://codereview.chromium.org/2635493002
Cr-Commit-Position: refs/heads/master@{#444131}

[modify] https://crrev.com/fa882b53462e83fd7a2470f375ee322f7c9c8914/android_webview/browser/aw_browser_terminator.cc
[modify] https://crrev.com/fa882b53462e83fd7a2470f375ee322f7c9c8914/android_webview/common/crash_reporter/aw_microdump_crash_reporter.cc
[modify] https://crrev.com/fa882b53462e83fd7a2470f375ee322f7c9c8914/android_webview/common/crash_reporter/aw_microdump_crash_reporter.h
[modify] https://crrev.com/fa882b53462e83fd7a2470f375ee322f7c9c8914/components/crash/content/app/breakpad_linux.cc
[modify] https://crrev.com/fa882b53462e83fd7a2470f375ee322f7c9c8914/components/crash/content/app/breakpad_linux.h