On google play app console, we found [signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)] crash rise suddenly in February 1st and happened on 7.0 system of mobile.
Through investigate, we found google play app console will only collect this native crash on 7.0 system of mobile, especially on SAMSUNG mobile galaxy s8+, galaxy note8, galaxy s8 etc.

signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)
base.apk
backtrace:
  native: pc 00000000029e9c74  /data/app/com.android.chrome-2/base.apk
  native: pc 00000000029e9c68  /data/app/com.android.chrome-2/base.apk

https://groups.google.com/forum/#!topic/google-admob-ads-sdk/I6giN0VbVa0

You can through the picture that i upload contain our app crash tendency and mobile Model
see image file:
crash_system.jpeg
crash_tendency.jpeg

You can find this crash happen on over 7.0 system of mobile and find it rise suddenly in early February.
Then we found Android System WebView 64.0.3282.137 is updated on January 31, 2018 by google official on google play. After January 31, 2018, this crash rise suddenly on our app in early February, and crash more and more.
At present，we collect some user Android system webview version who installed our app and get below information.
The percentage of client which installed Android System Webview 64.0.3282.137 is 37%
Between Android System Webview 53.0.2785.135 and 65.0.3325.144, the percent of client is 56%. 

Under 8.0 system of mobile , more user install the newest Android System WebView, more crash will happened on our app in the future. But we found Android System Webview 58.0.3029.83 is fine.

I hope this detail information can help your android webview team to find this bug soon and hope your team fix this bug on next webview version and make android webview chrome better.
Thanks!

Deleted: crash_system.jpeg 199 KB

	crash_system.jpeg 199 KB View Download

Deleted: crash_tendency.jpeg 83.1 KB

	crash_tendency.jpeg 83.1 KB View Download

Hi Guys!
We suspect that webview native memory grow fast with some malicious or bad js.
When webview load some malicious or bad js, the memory grow so fast and high.
When the memory grow high enough, the system of Android mobile will be kill the app immediately. 
And We received SIGABRT or signal 5 (SIGTRAP), code 1 (TRAP_BRKPT) crash logs on crash tracker console.

So, Our solution is decrease the count of the webview in one app and control the count of webview which execute to load js at the same time.
After we did it, the crash(signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)) grow slower than before. And the rate of crash is getting normal at present.

But this solution is not the best way for my app, the crash of rate will be grow in a future maybe. 
So i hope team of android system webview to check it as soon as possible.
If it were true, i hope fix it in next android system webview version. It's import for our app and other's app which use amounts of webview.
Thanks!

We have received a massive spike in these native Chrome crashes since March 7th here at Pandora. Since then, we are seeing up to a 5x increase to our daily overall crashes rate due to this issue. 

This crash kills our process before our internal bug reporting software can log an event, so we only have limited data from Google Play Console, but it all seems to match the symptoms listed in this ticket (although we are seeing similar lesser crashes occur at the same time on non-7.x Android versions). 

Vetting all javascript coming into our app through ads is extremely difficult, so this issue must be handled inside the WebView itself. A fast patch to the WebView or workaround would be greatly appreciated. 

I am very glad to see that others provide the same important information.
Thanks for the friend from pandora. 

We test it with Nexus 6 System 6.0.1, but the log of crash won't be collected by google play consle and also happen on 5.X. The google play console may be only collect little crash from system under 7.X.

Decrease the count of ads loading at the same time and control the count of ads, the crash will grow not so fast.

More and more people update system webview from google play with time goes by. 

cc'ing people who might be more familiar with memory.

does this reproduce?

After looking more into this, we came to exactly the same results as `yangzhen...`

NOTE: Many Samsung devices such as Samsung Galaxy Note 4 (SM-N910A, API23) won't even classify WebView consumed memory properly as `native heap` and will report it as `unknown`. Therefore, memory spikes will not be visible in Android Memory Profiler, but could be observed using `dumpsys meminfo`.

Deleted: android-studio.png 86.6 KB

	android-studio.png 86.6 KB View Download

Deleted: 65.0.3325.109-dumpsys.png 267 KB

	65.0.3325.109-dumpsys.png 267 KB View Download

assigning to ctzsm@ first
mariakhomenko@ & dskiba@, is this a known issue?

Not something I am aware of. +hpayer@ on the assumption this may be v8 since it depends on a specific script to execute.

As for the crash stack traces, could you please re-attach crash logs with the entire MICRODUMP attached?
i.e. everything from the line including
BEGIN BREAKPAD MICRODUMP
to
END BREAKPAD MICRODUMP
(including those two lines).

Note that this (native heap being eaten up in the app process using WebView) reproduces for me on ToT WebView, using a Nexus 5, running L.
It does seem to be flaky though (the memory doesn't always grow like crazy).

can you take a memory-infra trace and see where that memory is going?
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/memory-infra/

Internally we can see a big spike in V8 OOMs that peaked on March 9th, which appears to have resolved by March 13th. That might indicate a change in the JS being executed. Does the pandora app use JS for anything other than Ads?

The stack-traces don't show anything consistent in the allocations happening during these OOMs (i.e., the allocations are coming from multiple places in V8 -
 allocating maps, bytecode arrays, code, arrays, etc.), so I don't see anything in the that indicate a specific leak / allocation bug in any area of V8.

@tobiasjs@chromium.org we don't restrict JS usage for Ads purposes only, but based on our internal analytics for OOM crashes, we have a high confidence that bad JS comes to us externally through ads.

gsennton@chromium.org 

Mobile:HUAWEI-TLOOH
System: 5.0
ROM:EMUI 3.1
chrome version:64.0.3282.137

I test the case that webview haven't been added to the activity, the js will not execute and the memory is normal.
But i test the case that webview is added to the activity, the js will execute, the memory of mobile grow slowly and will be high in few minutes.

On system 5.0， the performance of webview's memory is better than 6.0 and 7.0.
see the image file: huawei_memory.png

After load 3 webview with bad js, the memory is not so high.

android code:
FrameLayout layout = new FrameLayout(this);
setContentView(layout);
for (int i = 0; i < 3; i++) {
    WebView webView = new WebView(this);
    layout.addView(webView);
    WebSettings webSettings = webView.getSettings();

    webSettings.setJavaScriptEnabled(true);
    webSettings.setDisplayZoomControls(false);
    webSettings.setLoadsImagesAutomatically(true);
    webSettings.setBuiltInZoomControls(true);
    webSettings.setDomStorageEnabled(true);
    webSettings.setSupportMultipleWindows(true);
    webView.loadUrl("file:///android_asset/js.html");
}

You could try this case on android mobile 6.0 or 7.0.
I hope this can help you!

Deleted: huawei_memory.png 123 KB

	huawei_memory.png 123 KB View Download

The example you have provided (logging to the console 100k times) seems like a case in which javascript might just take up a lot of memory (for whatever reason) - and I don't really see why you would be executing javascript like that (or why we would try to support a use-case like that).

If an ad is serving javascript like that then that ad should probably be restricted / removed.
Is that something we/you can do?

#17. Looking at crash timeseries, there are other that replicate that seem like they are probably ad-related, however the 4 day spike that Pandora observed was not seen by any other app. That would tend to argue against that specific event being ad-related. The median uptime was depressed during that time, but there was no indication that I can see that this was a startup crash.

We don't have any data that can provide any deeper insight. Maybe your analytics can?

gsennton@chromium.org The issue is the actual discrepancy in how different versions of WebView handle this sample javascript.

Versions 44 and 52 don't require much memory to process logging to console 100k times. Version 64 will take about 1GB of memory. Something has obviously changed in how heavy JS code is being internally processed. This means that ad creatives that were perfectly fine on version 52 will now result in OOM crashes.

I have been experiencing the same issue for my app in the past couple of months.
My crash rate is now around 8% because of this with above a million of monthly crash: signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)
This issue has been reported month ago. Many developers are facing the same issue because of the admob banner they are using.
Please take this issue seriously and fix it. I already submitted many micro dump to the admob team

I am here (and have starred this issue) because it's the only search hit on the issue tracker for "signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)". I have a hybrid app (AnkiDroid - it's open source and visible on github if that matters) that uses a WebView to load flashcards and can load arbitrary JS from users. I'm not sure what JS is being loaded by the users but this is my top crash now, by far, with a significant uptick since the current chrome (70.0.3538.110 for me) started rolling out on Android. Most visible on Android 8.0/8.1, with some on 7, no reports prior. Let me know if you need more information (and ideally, how to get it...)

TRAP_BRKPT just means "a fatal error/assertion was hit" and covers tens of thousands of different possible causes, so it's far from guaranteed that your issue is related to this one.

I'm guessing you're seeing this in the Play Store developer console? File a new WebView bug here with all of the crash information that you can see there (the entire output with the stack/registers/etc) for a start - if any of your users who are experiencing the crash are able to grab the "adb logcat" output when the crash happens, then attaching that would be extremely helpful. Also, please include the exact, full package name of your application as it's published on the Play Store (or just the full URL to the app on the Play Store) so we can look up your app in our crash database to see what's being reported via the webview crash system, as well as repeating all the information you posted here. If you can reproduce the issue yourself, then telling us how to do that would be the most useful thing, but I'm guessing you can't from your description.

In general, please always just file a new bug about issues you're having rather than replying to an existing issue, even if it looks similar to you (though feel free to mention the bug number you think it might be related to - that's helpful information). Our crashes are, unfortunately, not always easy to understand without experience in the chromium codebase, and we don't always notice replies to old bugs as the people involved in the bug may not be paying close attention. We have a dedicated bug triage rotation for newly filed bugs and someone will look at them pretty quickly in most cases.

Thanks @torne - sorry to clutter this issue then, and thank you for the detailed guidance