The problem
WebView component crashes Android emulator even when basic HTML is loaded.
This makes testing of app with WebView imposible. :(
Test case
Test case for this issue is very simple:
var win = Ti.UI.createWindow();
var webView = Ti.UI.createWebView();
webView.html = '<html><head><title></title></head><body>Testing testing .... </body></html>';
win.add(webView);
win.open();
Run this code on Android emulator and wait a bit until emulator crashes.
Here is error log:
10-25 11:40:30.056: W/dalvikvm(964): JNI WARNING: jarray 0x4058d540 points to non-array object (Ljava/lang/String;)
10-25 11:40:30.056: I/dalvikvm(964): "WebViewCoreThread" prio=5 tid=12 NATIVE
10-25 11:40:30.056: I/dalvikvm(964): | group="main" sCount=0 dsCount=0 obj=0x4055b4d8 self=0x1fad90
10-25 11:40:30.056: I/dalvikvm(964): | sysTid=976 nice=0 sched=0/0 cgrp=default handle=2385528
10-25 11:40:30.066: I/dalvikvm(964): | schedstat=( 262919029 305332027 68 )
10-25 11:40:30.076: I/dalvikvm(964): at android.webkit.JWebCoreJavaBridge.sharedTimerFired(Native Method)
10-25 11:40:30.076: I/dalvikvm(964): at android.webkit.JWebCoreJavaBridge.sharedTimerFired(Native Method)
10-25 11:40:30.076: I/dalvikvm(964): at android.webkit.JWebCoreJavaBridge.fireSharedTimer(JWebCoreJavaBridge.java:91)
10-25 11:40:30.086: I/dalvikvm(964): at android.webkit.JWebCoreJavaBridge.handleMessage(JWebCoreJavaBridge.java:108)
10-25 11:40:30.096: I/dalvikvm(964): at android.os.Handler.dispatchMessage(Handler.java:99)
10-25 11:40:30.096: I/dalvikvm(964): at android.os.Looper.loop(Looper.java:130)
10-25 11:40:30.096: I/dalvikvm(964): at android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:629)
10-25 11:40:30.096: I/dalvikvm(964): at java.lang.Thread.run(Thread.java:1019)
10-25 11:40:30.116: E/dalvikvm(964): VM aborting
10-25 11:40:30.236: I/DEBUG(815): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-25 11:40:30.236: I/DEBUG(815): Build fingerprint: 'generic/google_sdk/generic:2.3.4/GINGERBREAD/123630:eng/test-keys'
10-25 11:40:30.236: I/DEBUG(815): pid: 964, tid: 976 >>> hr.iskugor.test <<<
10-25 11:40:30.236: I/DEBUG(815): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
10-25 11:40:30.236: I/DEBUG(815): r0 fffffec4 r1 deadd00d r2 00000026 r3 00000000
10-25 11:40:30.236: I/DEBUG(815): r4 800a45c0 r5 4058d540 r6 80085acc r7 00246768
10-25 11:40:30.236: I/DEBUG(815): r8 45e0bb58 r9 4506bf0c 10 4506bef4 fp 437cd8ec
10-25 11:40:30.236: I/DEBUG(815): ip 800a4720 sp 45e0b678 lr afd19375 pc 80045a4a cpsr 20000030
10-25 11:40:30.686: I/DEBUG(815): #00 pc 00045a4a /system/lib/libdvm.so
10-25 11:40:30.686: I/DEBUG(815): #01 pc 00037748 /system/lib/libdvm.so
10-25 11:40:30.696: I/DEBUG(815): #02 pc 00039a10 /system/lib/libdvm.so
10-25 11:40:30.696: I/DEBUG(815): #03 pc 0003a4ec /system/lib/libdvm.so
10-25 11:40:30.696: I/DEBUG(815): #04 pc 0029864e /system/lib/libwebcore.so
10-25 11:40:30.696: I/DEBUG(815): #05 pc 00211d1c /system/lib/libwebcore.so
10-25 11:40:30.706: I/DEBUG(815): #06 pc 001133be /system/lib/libwebcore.so
10-25 11:40:30.706: I/DEBUG(815): #07 pc 002127e8 /system/lib/libwebcore.so
10-25 11:40:30.716: I/DEBUG(815): #08 pc 002c6de6 /system/lib/libwebcore.so
10-25 11:40:30.716: I/DEBUG(815): #09 pc 002ca13e /system/lib/libwebcore.so
10-25 11:40:30.726: I/DEBUG(815): #10 pc 002d8028 /system/lib/libwebcore.so
10-25 11:40:30.726: I/DEBUG(815): #11 pc 002cf760 /system/lib/libwebcore.so
10-25 11:40:30.736: I/DEBUG(815): #12 pc 0020fd0c /system/lib/libwebcore.so
10-25 11:40:30.736: I/DEBUG(815): #13 pc 0020fd8a /system/lib/libwebcore.so
10-25 11:40:30.746: I/DEBUG(815): #14 pc 0020fdf8 /system/lib/libwebcore.so
10-25 11:40:30.746: I/DEBUG(815): #15 pc 001e7e4e /system/lib/libwebcore.so
10-25 11:40:30.756: I/DEBUG(815): #16 pc 0007eae2 /system/lib/libwebcore.so
10-25 11:40:30.756: I/DEBUG(815): #17 pc 0007eb8c /system/lib/libwebcore.so
10-25 11:40:30.766: I/DEBUG(815): #18 pc 0011b21e /system/lib/libwebcore.so
10-25 11:40:30.766: I/DEBUG(815): #19 pc 00017d74 /system/lib/libdvm.so
10-25 11:40:30.766: I/DEBUG(815): #20 pc 00048f08 /system/lib/libdvm.so
10-25 11:40:30.776: I/DEBUG(815): #21 pc 00041ab6 /system/lib/libdvm.so
10-25 11:40:30.786: I/DEBUG(815): #22 pc 0001cfd4 /system/lib/libdvm.so
10-25 11:40:30.786: I/DEBUG(815): #23 pc 000220dc /system/lib/libdvm.so
10-25 11:40:30.796: I/DEBUG(815): #24 pc 00020fd0 /system/lib/libdvm.so
10-25 11:40:30.796: I/DEBUG(815): #25 pc 0005f430 /system/lib/libdvm.so
10-25 11:40:30.805: I/DEBUG(815): #26 pc 0005f656 /system/lib/libdvm.so
10-25 11:40:30.805: I/DEBUG(815): #27 pc 00053b4e /system/lib/libdvm.so
10-25 11:40:30.816: I/DEBUG(815): #28 pc 00011a7c /system/lib/libc.so
10-25 11:40:30.816: I/DEBUG(815): #29 pc 00011640 /system/lib/libc.so
10-25 11:40:30.826: I/DEBUG(815): code around pc:
10-25 11:40:30.826: I/DEBUG(815): 80045a28 447a4479 ed0cf7d1 20004c09 ee34f7d1
10-25 11:40:30.826: I/DEBUG(815): 80045a38 447c4808 6bdb5823 d0002b00 49064798
10-25 11:40:30.826: I/DEBUG(815): 80045a48 700a2226 eea0f7d1 000436b7 00045275
10-25 11:40:30.836: I/DEBUG(815): 80045a58 0005eb82 fffffec4 deadd00d b510b40e
10-25 11:40:30.836: I/DEBUG(815): 80045a68 4c0a4b09 447bb083 aa05591b 6b5bca02
10-25 11:40:30.836: I/DEBUG(815): code around lr:
10-25 11:40:30.836: I/DEBUG(815): afd19354 b0834a0d 589c447b 26009001 686768a5
10-25 11:40:30.836: I/DEBUG(815): afd19364 220ce008 2b005eab 1c28d003 47889901
10-25 11:40:30.846: I/DEBUG(815): afd19374 35544306 d5f43f01 2c006824 b003d1ee
10-25 11:40:30.846: I/DEBUG(815): afd19384 bdf01c30 000281a8 ffffff88 1c0fb5f0
10-25 11:40:30.846: I/DEBUG(815): afd19394 43551c3d a904b087 1c16ac01 604d9004
10-25 11:40:30.846: I/DEBUG(815): stack:
10-25 11:40:30.846: I/DEBUG(815): 45e0b638 00000015
10-25 11:40:30.846: I/DEBUG(815): 45e0b63c afd18407 /system/lib/libc.so
10-25 11:40:30.846: I/DEBUG(815): 45e0b640 afd4270c /system/lib/libc.so
10-25 11:40:30.856: I/DEBUG(815): 45e0b644 afd426b8 /system/lib/libc.so
10-25 11:40:30.856: I/DEBUG(815): 45e0b648 00000000
10-25 11:40:30.856: I/DEBUG(815): 45e0b64c afd19375 /system/lib/libc.so
10-25 11:40:30.866: I/DEBUG(815): 45e0b650 001fad90 [heap]
10-25 11:40:30.866: I/DEBUG(815): 45e0b654 afd183d9 /system/lib/libc.so
10-25 11:40:30.866: I/DEBUG(815): 45e0b658 00246768 [heap]
10-25 11:40:30.866: I/DEBUG(815): 45e0b65c 0005eb82 [heap]
10-25 11:40:30.876: I/DEBUG(815): 45e0b660 4058d540 /dev/ashmem/dalvik-heap (deleted)
10-25 11:40:30.876: I/DEBUG(815): 45e0b664 80085acc /system/lib/libdvm.so
10-25 11:40:30.876: I/DEBUG(815): 45e0b668 00246768 [heap]
10-25 11:40:30.876: I/DEBUG(815): 45e0b66c afd18437 /system/lib/libc.so
10-25 11:40:30.876: I/DEBUG(815): 45e0b670 df002777
10-25 11:40:30.886: I/DEBUG(815): 45e0b674 e3a070ad
10-25 11:40:30.886: I/DEBUG(815): #00 45e0b678 00000001
10-25 11:40:30.886: I/DEBUG(815): 45e0b67c 8003774d /system/lib/libdvm.so
10-25 11:40:30.896: I/DEBUG(815): #01 45e0b680 00000001
10-25 11:40:30.896: I/DEBUG(815): 45e0b684 80039a15 /system/lib/libdvm.so
This is emulator issue only, it does not happen on device.
Additional remarks
Crash is reproducible when WebView is idle for about 227 secs (up to 4 minutes inactivity...)Using a timer
Google APIs Android 2.3.3 & Titanium SDKs: 2.1.3.GA, 2.1.4.GA & 3.1.0 (2012/11/09 14:50 9390d4f)
Stack trace 2.1.3.GA
Stack trace - 2.1.4.GA
Seems like newer versions of Android emulator (4.*) handle this much better (they don't crash :D ). I didn't test with this particular test case, but works with more complex. So, it seems like this might be emulator 2.* issue.
I have also run across this exact problem of the last few days so I wanted to add some more information. Confirmed it is only on the Android emulator, and only for Android API < 4. For API 4+ the problem does not seem to occur. The problem also happens if you set
url
property instead ofhtml
property of WebView. If you view logcat or connect the emulator to DDMS, you can watch for this type of message appear:GREF has increased to 201
GREF has increased to 301
... All the way until it hits the default JNI limit of 2000 GREFs, at which point that is when the app crashes in the emulator. So something is causing these global references (GREFs) to accumulate regularly, and strangely it always seems to increment by 100. Of course there are ways to increase the JNI limit beyond 2000, but that does not really solve the leak. Here is a related [Q&A entry](http://developer.appcelerator.com/question/143491/android-sdk--210-excessive-jni-global-references)Pull pending https://github.com/appcelerator/titanium_mobile/pull/3932 The basic crash is due to incrementing GREF count which is tied into our polling code. What this PR does is wrap the eval code inside a function that returns a primitive (int) which does not increment the GREF count. Does not change any existing functionality So basically for simple webviews the developers should be ok. The crash will however occur once the getJSCode returns enough valid string values (basically GREF goes up by 2 on every valid return). So essentially this PR puts off the crash for some time but does not really fix it. Also added the annotation @JavascriptInterface and had to update the build files for that. See documentation [here](http://developer.android.com/reference/android/webkit/JavascriptInterface.html) This is a problem on emulators only.
Tested with: SDK: 3.1.0.v20130313215655 Studio: 3.0.2.201302191606 device: Android Emulator OS:OSX10.7.5 No crash with basic HTML