Which package are you actually using as the webview implementation on your device? You mention a webview version and also a chrome beta version; what's selected as the provider?

Please provide a bugreport, or at least the full log.

This is likely my fault. Microdumping was broken between 57.0.2987.0 and 58.0.2993.0.

It's also fixed on the m57 branch by https://chromereviews.googleplex.com/567907016/, but I don't know what revision that corresponds to.

The breakpad roll went into 57.0.2987.11, so if the reporter is using that beta as their webview implementation it should already be fixed.

Please just give us a full log/bugreport; a single line out of context like this is useless (I did request this on the other bug).

The WebView implementation in My Nexus 6 is Chrome Beta 57.0.2987.19, bugreport attached.
But breakpad doesn't work neither if switching to Chrome Stable 53.0.2785.135.

Deleted: bugreport-N6F26Q-2017-02-06-10-16-13.zip 1.4 MB

bugreport-N6F26Q-2017-02-06-10-16-13.zip 1.4 MB Download

Can you also provide the log of what happens when you try with 53?

I can't reproduce this - using the exact same build on a nexus 6 and the same chrome beta 57.0.2987.19, I get a microdump when I kill -11 the htmlviewer process.

I notice you're running "com.android.browser" - what actual app is this? We removed the stock browser from AOSP some time ago and it's no longer maintained or supported. Maybe whatever app you have there is doing something weird with signal handling?

Try reproducing using another webview app; HTMLViewer?

I attach the log running htmlviewer wich using WebView implementation: Chrome Stable 53.0.2785.135

Deleted: bugreport-N6F26Q-2017-02-07-09-06-44.zip 1.7 MB

bugreport-N6F26Q-2017-02-07-09-06-44.zip 1.7 MB Download

So that log shows the exact same behaviour.

We definitely can't reproduce this. It works perfectly for me on the exact same build and device, and we get reports from the field demonstrating that it works for the general population as well.

It seems like it must be some issue with how you're setting up the devices you're using to test this. One thing that I notice is that you're running adb shell as root to be able to kill the process, but you're testing on a user/release-keys build. How are you running adb as root on this device? user builds don't permit root access. Have you installed a root exploit? (because that might have changed/broken basically anything about the system).

Yes, the Nexus 6 is rooted for debug purpose. Would you provide the steps to trigger breakpad microdump without root? Our reference devices are using user/release-keys build.

We think the breakpad problem we Encountered is a platform issue: breakpad tried to open a file (/proc/<crashed_process_pid>/auxv) from the child process, and the return value is -1 (EPERM? Operation not permitted). But we don't find related SELinux error in log. 

 

Loading chrome://crash in a webview will cause a deliberate crash. You can do this with any browser-like app that has a URL bar (such as the webview test shell), or by just calling loadUrl from an app.

There's not much point in testing things on a device rooted using third party tools - this is a modified image that no longer has any guarantees about how it behaves. If you need root capabilities you should just build your own userdebug or eng image from AOSP source code, not hack up a user build.

/proc/<pid>/auxv is opened successfully on all devices/versions I've tested on. There's no evidence that there's a general platform issue here: we get plenty of crash reports with microdumps across all OS versions and device types from the field.

Update status:
Breakpad works when running webview shell test, both Nexus 6 and Mediatek based devices.

OK, so that sounds like breakpad is working as expected and your issues are caused by some modification made by whatever third party tools you were using to get root on a user image. That still doesn't explain why it wasn't working in  issue 684217  though, which was a real crash happening on an eng image where presumably you hadn't modified the system in weird ways. Is that issue still reproducible for you?

This is probably a dupe of Issue 748414

Closing this because it sounds like it's not reproducible anymore (re #12).

Primiano, feel free to dupe this against your issue.