Lots of native Android crashes coming from WebView / Chromium
Reported by
vladik.t...@gmail.com,
Jul 24 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: Can't reproduce myself, only have the crash reports from Google Play Store What is the expected behavior? What went wrong? For context: I'm an Android developer for the Desygner app, which offers a JS based editor for creating designs consisting of SVG images, texts, shapes etc. Obviously, this heavily relies on the Android system web view. The issues: We are receiving about 300 native crash reports in the Google Play developer console and they always point to Chromium, Chrome, WebView or SSL. Since we have no idea what to do with them, I hoped someone here would be able to track down the origin of at least some of the crashes, or at least have an idea of what's happening. The logs below are the only info we have about the crashes. device info: only on Android 4.4, mostly Samsung in tgkill backtrace: native: pc 0000000000022164 /system/lib/libc.so (tgkill+12) native: pc 0000000000013201 /system/lib/libc.so (pthread_kill+48) native: pc 0000000000013415 /system/lib/libc.so (raise+10) native: pc 00000000000120e3 /system/lib/libc.so native: pc 0000000000021a18 /system/lib/libc.so (abort+4) native: pc 00000000001c5119 /system/lib/libwebviewchromium.so native: pc 00000000001c26bb /system/lib/libwebviewchromium.so native: pc 00000000008e90df /system/lib/libwebviewchromium.so native: pc 00000000008e6271 /system/lib/libwebviewchromium.so native: pc 000000000091986f /system/lib/libwebviewchromium.so native: pc 0000000000918ce5 /system/lib/libwebviewchromium.so native: pc 0000000000912b17 /system/lib/libwebviewchromium.so native: pc 00000000001ed439 /system/lib/libwebviewchromium.so native: pc 00000000001ed211 /system/lib/libwebviewchromium.so native: pc 00000000001cfc6f /system/lib/libwebviewchromium.so native: pc 00000000001d0771 /system/lib/libwebviewchromium.so native: pc 00000000001d08cf /system/lib/libwebviewchromium.so native: pc 00000000001e06af /system/lib/libwebviewchromium.so native: pc 0000000000020d0c /system/lib/libdvm.so (dvmPlatformInvoke+112) native: pc 00000000000519af /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398) native: pc 0000000000000214 /dev/ashmem/dalvik-jit-code-cache (deleted) device info: only on Android 5.0, and almost exclusively happening on Huawei P8 Lite (hwALE-H), P8 (HWGRA) and X2 (HWGemini) in tgkill backtrace: native: pc 000000000004276c /system/lib/libc.so (tgkill+12) native: pc 0000000000040379 /system/lib/libc.so (pthread_kill+32) native: pc 000000000001ca9b /system/lib/libc.so (raise+10) native: pc 0000000000019d19 /system/lib/libc.so (__libc_android_abort+34) native: pc 000000000001755c /system/lib/libc.so (abort+4) native: pc 00000000002a079d /data/app/com.google.android.webview-2/lib/arm/libwebviewchromium.so device info: Android 5 and above in tgkill backtrace: native: pc 0000000000069454 /system/lib64/libc.so (tgkill+8) native: pc 0000000000066be4 /system/lib64/libc.so (pthread_kill+68) native: pc 0000000000023950 /system/lib64/libc.so (raise+28) native: pc 000000000001e280 /system/lib64/libc.so (abort+60) native: pc 000000000073f210 /data/app/com.google.android.webview-1/lib/arm64/libwebviewchromium.so device info: only on Android 6.0 in tgkill backtrace: native: pc 00000000000427bc /system/lib/libc.so (tgkill+12) native: pc 00000000000403c9 /system/lib/libc.so (pthread_kill+32) native: pc 000000000001caab /system/lib/libc.so (raise+10) native: pc 0000000000019d29 /system/lib/libc.so (__libc_android_abort+34) native: pc 000000000001756c /system/lib/libc.so (abort+4) native: pc 00000000002b1945 /system/app/WebViewGoogle/WebViewGoogle.apk device info: only on Android 7.0 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in base.apk backtrace: native: pc 000000000144fe76 /data/app/com.android.chrome-1/base.apk device info: only on Android 7.0/7.1 in tgkill backtrace: native: pc 000000000006bc30 /system/lib64/libc.so (tgkill+8) native: pc 00000000000690cc /system/lib64/libc.so (pthread_kill+64) native: pc 0000000000023e68 /system/lib64/libc.so (raise+24) native: pc 000000000001c8ec /system/lib64/libc.so (abort+52) native: pc 0000000000749568 /system/app/Chrome/Chrome.apk device info: only on Android 7.0/7.1, mostly Samsung in tgkill backtrace: native: pc 000000000006b5b4 /system/lib64/libc.so (tgkill+8) native: pc 0000000000068a50 /system/lib64/libc.so (pthread_kill+64) native: pc 0000000000023f68 /system/lib64/libc.so (raise+24) native: pc 000000000001c9ec /system/lib64/libc.so (abort+52) native: pc 000000000073f210 /data/app/com.android.chrome-1/base.apk device info: only on Android 7.0/7.1, mostly Samsung in tgkill backtrace: native: pc 000000000004ad20 /system/lib/libc.so (tgkill+12) native: pc 00000000000484b3 /system/lib/libc.so (pthread_kill+34) native: pc 000000000001dd89 /system/lib/libc.so (raise+10) native: pc 0000000000019511 /system/lib/libc.so (__libc_android_abort+34) native: pc 0000000000017150 /system/lib/libc.so (abort+4) native: pc 0000000000957985 /data/app/com.android.chrome-1/base.apk device info: only on Android 4.4 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in dlfree backtrace: native: pc 0000000000011914 /system/lib/libc.so (dlfree+1191) native: pc 000000000000ddb3 /system/lib/libc.so (free+10) native: pc 0000000000083903 /system/lib/libcrypto.so (CRYPTO_free+34) native: pc 000000000002f673 /system/lib/libssl.so (ssl_parse_serverhello_tlsext+738) native: pc 000000000001817b /system/lib/libssl.so (ssl3_get_server_hello+1018) native: pc 000000000001756f /system/lib/libssl.so (ssl3_connect+566) native: pc 0000000000027f1b /system/lib/libssl.so (SSL_do_handshake+50) native: pc 000000000000c715 /system/lib/libjavacrypto.so native: pc 00000000000207cc /system/lib/libdvm.so (dvmPlatformInvoke+112) native: pc 00000000000514af /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398) native: pc 0000000000029c60 /system/lib/libdvm.so native: pc 0000000000031144 /system/lib/libdvm.so (dvmMterpStd(Thread*)+76) native: pc 000000000002e7dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184) native: pc 0000000000063911 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+336) native: pc 0000000000063935 /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20) native: pc 0000000000058613 /system/lib/libdvm.so native: pc 000000000000d318 /system/lib/libc.so (__thread_entry+72) native: pc 000000000000d4b0 /system/lib/libc.so (pthread_create+240) device info: only on Android 5.0, and almost exclusively happening on Huawei P8 Lite (hwALE-H), P8 (HWGRA) and X2 (HWGemini) signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in dlfree backtrace: native: pc 0000000000041e4c /system/lib64/libc.so (dlfree+408) native: pc 00000000000176c4 /system/lib64/libc.so (free+20) native: pc 00000000000e7988 /system/lib64/libcrypto.so (CRYPTO_free+60) native: pc 000000000004800c /system/lib64/libssl.so (ssl_parse_serverhello_tlsext+876) native: pc 0000000000028104 /system/lib64/libssl.so (ssl3_get_server_hello+1372) native: pc 0000000000026f48 /system/lib64/libssl.so (ssl3_connect+804) native: pc 00000000000198e0 /system/lib64/libjavacrypto.so native: pc 00000000004883c0 /data/dalvik-cache/arm64/system@framework@boot.oat Did this work before? No Does this work in other browsers? N/A Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version:
,
Jul 26 2017
,
Jul 26 2017
Unfortunately there's not much information to go on here. Looking through the recorded crashes, it seems most are aborts, which can often be blamed on an exception in a JNI call. In this case, I think it might well be in the ValueCallback<String> that you passed to evaluateJavaScript. It's very hard to verify this without logs (that aren't collected by feedback) that give the Java stacktrace. I hope this helps, but unfortunately there's not much more that we can do here without further information.
,
Jul 27 2017
Hi, I see, so will have to track it down in the JS parts. But do you have an idea why they would be so extremely OS/device dependent, or can they (apart from the Huawei crashes) actually be the same issues, just the abort happening in different places due to differences in the OS version?
,
Jul 27 2017
The exception would be in your Java code, not the JS. When your Java code implements callback functions called by WebView (e.g. overriding methods of WebViewClient/WebChromeClient, or overriding ValueCallback.onReceiveValue), it's important that you don't throw any Java exceptions (e.g. allowing a NullPointerException to escape because of something not being in the state you think it's in), because when you throw an exception in these callbacks it will crash in native code due to how the JNI interface works, and you'll "lose" the java exception stack. We're making changes to WebView to make this easier to debug but it's still in progress. This is a very common reason for app bugs. The issues that aren't calls to abort() from webview are probably something else. We can't really do anything useful about crashes on pre-5.0 because webview isn't updatable and in some cases has been customised by the device vendor. The last crash from libcrypto doesn't appear to be related to webview at all.
,
Jul 28 2017
Thanks, wow, that's really helpful! 6 years of Android development and no idea this was the case. If someone stumbles upon this thread: The real exceptions and stack traces can be made visible by posting to the UI thread inside the callback.
,
Jul 28 2017
The exceptions and stack traces are still printed in the logs, it's just that the feedback system doesn't give you the logs from end users' devices. If you're developing/debugging locally you have always been able to see them. We're working on changing WebView to make these callbacks in a different way that will give app developers the normal Java exceptions without needing to change your code - some callbacks have already been converted and more are being worked on.
,
Jul 31 2017
The Java exception stack is printed *before* the native abort - you will have to scroll back several hundred lines to before the large hex-encoded microdump for the native crash.
,
Jul 31 2017
You're right, I didn't see it because exception stack traces are normally correctly printed with ERROR priority, but in case of a native abort it's printed to the Java System.err stream. Probably not intended that way? Anyway, after handling all exceptions thrown inside ValueCallbacks, there are fewer aborts, but there are still native crashes occurring outside of any ValueCallbacks. Again they say /system/app/webview/webview.apk, /data/app/com.google.android.webview-2/lib/arm/libwebviewchromium.so or something similar. Is there anywhere else they might be caused by Java exceptions, or does that mean they are actual crashes inside the web view or Chromium?
,
Aug 1 2017
The exception is printed by the standard JNI exception handling code in the VM - we don't control what stream it's printed to or at what priority. ValueCallback is just one example of a place where we call Java callbacks from native - most methods on WebViewClient and WebChromeClient work the same way, as do other callbacks used in webview (since pretty much the whole of webview is native code). To investigate any particular crash we need to know the exact WebView version used on the device that's crashing.
,
Aug 10 2017
I just had an abort on my own phone. Just 2 seconds before it crashed, the web view became completely black. I wasn't even touching the web view, so I have no idea what might have caused the crash. I can't access the tombstone file without root, but I attached all log cat entries.
,
Aug 10 2017
Looks like an OOM crash. Can't symbolise this because it's so badly out of memory that it's unable to determine the module ID of the library; would need to know the exact webview version you have installed to decode it, but it's unlikely to tell us much that's interesting - the huge number of OOM errors coming from the video driver are already what wrecked everything. Doesn't mean the video driver is necessarily to blame for the memory usage - it might have just been the last straw. Not a lot we can do about this in general. 32-bit devices are extremely starved for address space on android and even a small leak in a video driver or chromium or your app or the framework can cause you to run out in some particular circumstance (plus, it's entirely possible to run out without any memory leaks at all - there's just not enough for even some totally legitimate cases). |
|||
►
Sign in to add a comment |
|||
Comment 1 by brajkumar@chromium.org
, Jul 24 2017