信号11 SIGSEGV在Galaxy S3 Android WebView中崩溃

我在Android WebView中有一个复杂的交互式HTML5,并且基本上除Galaxy S3以外的所有平台都能正常工作。 在Galaxy S3(Android 4.0.4)上,每5次左右一次,加载完成后,/system/lib/libwebcore.so尝试访问无效的内存,并在[各个地址处发送致命信号11(SIGSEGV) ](代码= 1)被抛出。

HTML5是一个微小的战斗,敌人出现,用户大幅度削减他们的行动。 在战斗之间是正常的html页面:普通页面 – > HTML5战斗 – >普通页面 – > HTML5战斗 – >普通页面 – > HTML5战斗。 HTML5没有做任何特别的开箱即用 – 有很多-webkit-animation调用…

.enemy { position:absolute; opacity:0; -webkit-animation:enemyAnim 0.6s linear 0.2s; } 

…引用了很多-webkit关键帧…

 @-webkit-keyframes enemyAnim { from { -webkit-transform: matrix(1, 0, 0, 1, 144.25, 150.25) scale(1, 1); opacity:1; } 8.33% { -webkit-transform: matrix(1, 0, 0, 1, 189.406, 102.206) scale(1.3066, 1.3066); opacity:1; } 16.66% { -webkit-transform: matrix(1, 0, 0, 1, 200.424, 82.649) scale(1.414, 1.414); opacity:1; } /*…*/ 

还有一个相当复杂的div树,但没有什么特别的实验。 有一些Javascript的级别,但即使所有Javascriptclosures,挂起似乎也会发生。

有没有人有一个银河S3正在…不同的问题? 没有Android 2.x设备有这个问题,甚至一个运行4.1.1的Galaxy Nexus似乎没有任何特别的问题。 我从来没有被诱惑写信给堆栈溢出,但这真让我烦恼…

search“Android WebView sigsegv crash”和“4.0.4 WebView sigsegv crash”提供了几个问题,但是:

  • webview.clearCache()/ webView.destroyDrawingCache()似乎没有效果(虽然这个挂起显然是一个内存问题,添加/删除System.gc()s在各个地方没有很好的结果) 信号11 SIGSEGV崩溃Android的

  • 没有使用canvas在Android 4.0.3上的canvas上奇怪的崩溃画。 A / libc:致命的信号11(SIGSEGV) (是的,我知道 – 调用这个页面HTML5是有点延伸)

  • 在Webview.clearView()之后执行WebView.loadurl()时,没有使用clearView()多点会导致崩溃

  • 如http://code.google.com/p/android/issues/detail?id=16563中没有使用preserve-3d

  • 我查看了android webkit的更新列表,在4.0.4之后寻找可疑的修复,并且认为我在下面有一些东西,但是将S3根植到4.1.1并没有解决这个问题: https:// github。 COM / teamgummy / android_external_webkit /提交/ 61e0d189f2b74650bf72a6a2820f66a8b17c3d06

由于一些崩溃是在内存释放()时发生的,我知道在崩溃的时候事情正在被释放,而我的直觉是有些东西正在被中间渲染,不应该被释放。 这很令人沮丧,因为SIGSEGV在纯HTML,JS和CSS = /

下面是一个示例崩溃报告。 请注意,碰撞位置不限于以下; 事故报告似乎没有太大的差异,但地点似乎有一些变化。

 10-08 17:34:06.605: I/DEBUG(524): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 10-08 17:34:06.605: I/DEBUG(524): Build fingerprint: 'samsung/m0xx/m0:4.0.4/IMM76D/I9300XXBLH1:user/release-keys' 10-08 17:34:06.605: I/DEBUG(524): pid: 7443, tid: 7443 >>> cool.tiny.rpg.battle <<< 10-08 17:34:06.605: I/DEBUG(524): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad 10-08 17:34:06.605: I/DEBUG(524): r0 deadbaad r1 00000001 r2 40000000 r3 00000000 10-08 17:34:06.605: I/DEBUG(524): r4 00000000 r5 00000027 r6 400d8540 r7 400e74f4 10-08 17:34:06.605: I/DEBUG(524): r8 01fa7160 r9 00000000 10 bed6a584 fp 41d79970 10-08 17:34:06.605: I/DEBUG(524): ip ffffffff sp bed6a2b0 lr 400b9639 pc 400b59c8 cpsr 68000030 10-08 17:34:06.605: I/DEBUG(524): d0 0000000000000000 d1 4343000000000000 10-08 17:34:06.605: I/DEBUG(524): d2 43b6800041a00000 d3 41a8000043020000 10-08 17:34:06.610: I/DEBUG(524): d4 8000000000000000 d5 43aa00003f800000 10-08 17:34:06.610: I/DEBUG(524): d6 43a4000043430000 d7 43cb000041a00000 10-08 17:34:06.610: I/DEBUG(524): d8 4082f00000000000 d9 4082f4000000025e 10-08 17:34:06.610: I/DEBUG(524): d10 4460400000000500 d11 0000000000000000 10-08 17:34:06.610: I/DEBUG(524): d12 0000000000000000 d13 0000000000000000 10-08 17:34:06.610: I/DEBUG(524): d14 0000000000000000 d15 0000000000000000 10-08 17:34:06.610: I/DEBUG(524): d16 4076800000000000 d17 7e37e43c8800759c 10-08 17:34:06.610: I/DEBUG(524): d18 0000000000000000 d19 0000000000000000 10-08 17:34:06.610: I/DEBUG(524): d20 3ff0000000000000 d21 8000000000000000 10-08 17:34:06.610: I/DEBUG(524): d22 0000000000000000 d23 0000000000000000 10-08 17:34:06.610: I/DEBUG(524): d24 0000000000000000 d25 3ff0000000000000 10-08 17:34:06.610: I/DEBUG(524): d26 4034000000000000 d27 3ff0000000000000 10-08 17:34:06.610: I/DEBUG(524): d28 0000000000000000 d29 3ff0000000000000 10-08 17:34:06.610: I/DEBUG(524): d30 0000000000000000 d31 3ff0000000000000 10-08 17:34:06.610: I/DEBUG(524): scr 60000010 10-08 17:34:06.750: I/DEBUG(524): #00 pc 000179c8 /system/lib/libc.so 10-08 17:34:06.750: I/DEBUG(524): #01 pc 00013852 /system/lib/libc.so 10-08 17:34:06.750: I/DEBUG(524): #02 pc 00015b90 /system/lib/libc.so (dlfree) 10-08 17:34:06.750: I/DEBUG(524): #03 pc 00016208 /system/lib/libc.so (free) 10-08 17:34:06.750: I/DEBUG(524): #04 pc 0010f79c /system/lib/libwebcore.so (_Z6yyfreePvS_) 10-08 17:34:06.750: I/DEBUG(524): #05 pc 0010ef70 /system/lib/libwebcore.so 10-08 17:34:06.750: I/DEBUG(524): #06 pc 003ee8ec /system/lib/libwebcore.so 10-08 17:34:06.755: I/DEBUG(524): #07 pc 003eef44 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev) 10-08 17:34:06.755: I/DEBUG(524): #08 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev) 10-08 17:34:06.755: I/DEBUG(524): #09 pc 0019b2ca /system/lib/libwebcore.so 10-08 17:34:06.755: I/DEBUG(524): #10 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv) 10-08 17:34:06.755: I/DEBUG(524): #11 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev) 10-08 17:34:06.760: I/DEBUG(524): #12 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev) 10-08 17:34:06.760: I/DEBUG(524): #13 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev) 10-08 17:34:06.760: I/DEBUG(524): #14 pc 0019b2ca /system/lib/libwebcore.so 10-08 17:34:06.760: I/DEBUG(524): #15 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv) 10-08 17:34:06.760: I/DEBUG(524): #16 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev) 10-08 17:34:06.760: I/DEBUG(524): #17 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev) 10-08 17:34:06.760: I/DEBUG(524): #18 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev) 10-08 17:34:06.760: I/DEBUG(524): #19 pc 0019b2ca /system/lib/libwebcore.so 10-08 17:34:06.760: I/DEBUG(524): #20 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv) 10-08 17:34:06.765: I/DEBUG(524): #21 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev) 10-08 17:34:06.765: I/DEBUG(524): #22 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev) 10-08 17:34:06.765: I/DEBUG(524): #23 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev) 10-08 17:34:06.765: I/DEBUG(524): #24 pc 0019b2ca /system/lib/libwebcore.so 10-08 17:34:06.765: I/DEBUG(524): #25 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv) 10-08 17:34:06.765: I/DEBUG(524): #26 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev) 10-08 17:34:06.765: I/DEBUG(524): #27 pc 003eef70 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD1Ev) 10-08 17:34:06.765: I/DEBUG(524): #28 pc 003eef84 /system/lib/libwebcore.so (_ZN7WebCore12LayerAndroidD0Ev) 10-08 17:34:06.770: I/DEBUG(524): #29 pc 0019b2ca /system/lib/libwebcore.so 10-08 17:34:06.770: I/DEBUG(524): #30 pc 003ec6a0 /system/lib/libwebcore.so (_ZN5Layer14removeChildrenEv) 10-08 17:34:06.770: I/DEBUG(524): #31 pc 003ec782 /system/lib/libwebcore.so (_ZN5LayerD2Ev) 10-08 17:34:06.770: I/DEBUG(524): memory map around addr deadbaad: 10-08 17:34:06.770: I/DEBUG(524): bed4a000-bed6b000 [stack] 10-08 17:34:06.770: I/DEBUG(524): (no map for address) 10-08 17:34:06.770: I/DEBUG(524): ffff0000-ffff1000 [vectors] 10-08 17:34:06.770: I/DEBUG(524): stack: 10-08 17:34:06.770: I/DEBUG(524): bed6a270 00000001 10-08 17:34:06.770: I/DEBUG(524): bed6a274 bed6a2b0 [stack] 10-08 17:34:06.770: I/DEBUG(524): bed6a278 400e2800 /system/lib/libc.so 10-08 17:34:06.770: I/DEBUG(524): bed6a27c 0000000c 10-08 17:34:06.770: I/DEBUG(524): bed6a280 400e2794 /system/lib/libc.so 10-08 17:34:06.770: I/DEBUG(524): bed6a284 400e7888 10-08 17:34:06.770: I/DEBUG(524): bed6a288 00000000 10-08 17:34:06.770: I/DEBUG(524): bed6a28c 400b9639 /system/lib/libc.so 10-08 17:34:06.770: I/DEBUG(524): bed6a290 00000000 10-08 17:34:06.770: I/DEBUG(524): bed6a294 bed6a2c4 [stack] 10-08 17:34:06.770: I/DEBUG(524): bed6a298 400d8540 /system/lib/libc.so 10-08 17:34:06.770: I/DEBUG(524): bed6a29c 400e74f4 10-08 17:34:06.775: I/DEBUG(524): bed6a2a0 01fa7160 [heap] 10-08 17:34:06.775: I/DEBUG(524): bed6a2a4 400b87a5 /system/lib/libc.so 10-08 17:34:06.775: I/DEBUG(524): bed6a2a8 df0027ad 10-08 17:34:06.775: I/DEBUG(524): bed6a2ac 00000000 10-08 17:34:06.775: I/DEBUG(524): #00 bed6a2b0 bed6a2ac [stack] 10-08 17:34:06.775: I/DEBUG(524): bed6a2b4 00000001 10-08 17:34:06.775: I/DEBUG(524): bed6a2b8 400d8524 /system/lib/libc.so 10-08 17:34:06.775: I/DEBUG(524): bed6a2bc 00000005 10-08 17:34:06.775: I/DEBUG(524): bed6a2c0 bed6a2dc [stack] 10-08 17:34:06.775: I/DEBUG(524): bed6a2c4 fffffbdf 10-08 17:34:06.775: I/DEBUG(524): bed6a2c8 bed6a2dc [stack] 10-08 17:34:06.775: I/DEBUG(524): bed6a2cc bed6a2dc [stack] 10-08 17:34:06.775: I/DEBUG(524): bed6a2d0 400dbaac /system/lib/libc.so 10-08 17:34:06.775: I/DEBUG(524): bed6a2d4 400b1857 /system/lib/libc.so 10-08 17:34:06.775: I/DEBUG(524): #01 bed6a2d8 00000130 10-08 17:34:06.775: I/DEBUG(524): bed6a2dc 20404040 10-08 17:34:06.775: I/DEBUG(524): bed6a2e0 524f4241 /dev/ashmem/dalvik-mark-stack (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2e4 474e4954 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2e8 4e49203a /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2ec 494c4156 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2f0 45482044 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2f4 41205041 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2f8 45524444 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a2fc 49205353 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.775: I/DEBUG(524): bed6a300 6c64204e 10-08 17:34:06.775: I/DEBUG(524): bed6a304 65657266 10-08 17:34:06.775: I/DEBUG(524): bed6a308 01f86700 [heap] 10-08 17:34:06.775: I/DEBUG(524): bed6a30c 406f6a2c /system/lib/libskia.so 10-08 17:34:06.775: I/DEBUG(524): bed6a310 406c4ecc /system/lib/libskia.so 10-08 17:34:06.775: I/DEBUG(524): bed6a314 3ff00000 10-08 17:34:06.775: I/DEBUG(524): bed6a318 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a31c 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a320 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a324 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a328 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a32c 01c9aa08 [heap] 10-08 17:34:06.775: I/DEBUG(524): bed6a330 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a334 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a338 00000000 10-08 17:34:06.775: I/DEBUG(524): bed6a33c 3ff00000 10-08 17:34:06.775: I/DEBUG(524): bed6a340 60d00000 10-08 17:34:06.775: I/DEBUG(524): bed6a344 60e42ff0 10-08 17:34:06.775: I/DEBUG(524): bed6a348 014bb000 10-08 17:34:06.775: I/DEBUG(524): bed6a34c 400e74f4 10-08 17:34:06.775: I/DEBUG(524): bed6a350 01bc24b0 [heap] 10-08 17:34:06.775: I/DEBUG(524): bed6a354 400e7550 10-08 17:34:06.775: I/DEBUG(524): bed6a358 01f74458 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a35c 400e7528 10-08 17:34:06.780: I/DEBUG(524): bed6a360 00000010 10-08 17:34:06.780: I/DEBUG(524): bed6a364 400e74f4 10-08 17:34:06.780: I/DEBUG(524): bed6a368 01f74460 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a36c 00000000 10-08 17:34:06.780: I/DEBUG(524): bed6a370 bed6a584 [stack] 10-08 17:34:06.780: I/DEBUG(524): bed6a374 400b3ba9 /system/lib/libc.so 10-08 17:34:06.780: I/DEBUG(524): bed6a378 0211c9a0 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a37c 020d499c [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a380 000097a0 /system/bin/app_process 10-08 17:34:06.780: I/DEBUG(524): bed6a384 00004000 10-08 17:34:06.780: I/DEBUG(524): bed6a388 01d087b8 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a38c 400e7560 10-08 17:34:06.780: I/DEBUG(524): bed6a390 01dc6ef8 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a394 400e7528 10-08 17:34:06.780: I/DEBUG(524): bed6a398 01fd5378 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a39c 400e7580 10-08 17:34:06.780: I/DEBUG(524): bed6a3a0 01ddafa8 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3a4 01ddb008 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3a8 01ed4568 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3ac 400e7580 10-08 17:34:06.780: I/DEBUG(524): bed6a3b0 00000068 10-08 17:34:06.780: I/DEBUG(524): bed6a3b4 400e74f4 10-08 17:34:06.780: I/DEBUG(524): bed6a3b8 01ed4570 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3bc 00000014 10-08 17:34:06.780: I/DEBUG(524): bed6a3c0 00000000 10-08 17:34:06.780: I/DEBUG(524): bed6a3c4 400b3ba9 /system/lib/libc.so 10-08 17:34:06.780: I/DEBUG(524): bed6a3c8 00000000 10-08 17:34:06.780: I/DEBUG(524): bed6a3cc 01ae77d8 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3d0 01fa7160 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3d4 01fd7d2c [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3d8 00000009 10-08 17:34:06.780: I/DEBUG(524): bed6a3dc 4dfa26b2 /dev/ashmem/dalvik-heap (deleted) 10-08 17:34:06.780: I/DEBUG(524): bed6a3e0 01fa7158 [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3e4 01fd7d2c [heap] 10-08 17:34:06.780: I/DEBUG(524): bed6a3e8 00000009 10-08 17:34:06.780: I/DEBUG(524): bed6a3ec 400b3b95 /system/lib/libc.so 

11月30日更新:

我还有很长的一段路要缩小到一个简单的testing案例,但我已经从上一个简单的webview应用程序加载上述SIGSEGV复制到2个HTML页面。 webview只是启动并加载:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html

这些页面相互链接,并不一定会在第一个视图上崩溃,但最终他们崩溃在Android 4.1.1模拟器和我的Galaxy Nexus(4.1.1)100%。 请注意,post标题是错误的 – 这肯定不是S3。

有趣的是,
– 在我的真实应用程序中使用webview,重复加载1页(crash.html或任何沉重的HTML5页面)足以导致SIGSEGV。
– 使用这个简单的webview应用程序进行testing,两个页面需要对方崩溃 – 只是重复加载1页不会死。
– 在Android 4.1.1网页浏览器中加载页面,即使是2页也不够 – 它会死掉,但是会占用很多页面。

就错误位置而言,崩溃时有不同的堆栈跟踪,一些与样式表相关,另一些与HTMLImageElement的析构函数相关。 Android 2.x,iOS,任何其他浏览器都是坚如磐石的。

Javascript改变了DOM,这似乎足以造成这里的崩溃…但是为什么?
乍看之下,这就像一个垃圾回收问题 – 我的应用程序会比普通的webview应用程序更早收集垃圾,因为它在其他地方使用了更多的内存。 我没有收到内存错误消息,但是。 我会继续努力缩小这个范围,但是对于如何进行或者可能是什么问题有任何想法的人,都有我永恒的不朽的感情。

testing应用代码:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip

testing应用APK:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk

所有HTML资源:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip

testing应用程序的启动代码:

  public class MainActivity extends Activity { private WebView webView; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); webView = (WebView) findViewById(R.id.webView1); webView.getSettings().setJavaScriptEnabled(true); webView.setWebViewClient(new WebViewClient()); webView.setWebChromeClient(new WebChromeClient()); webView.loadUrl("http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html"); } } 

2月3日更新:

这个问题似乎是由于Webkitanimation在页面closures时仍然animation的情况下发生的。 我缩小了一个崩溃到一个“myblink”标签:

 .myblink{-webkit-animation-name:"anime-blink";-webkit-animation-duration:1.2s;-webkit-animation-timing-function:ease-in-out;-webkit-animation-iteration-count:infinite} @-webkit-keyframes "anime-blink"{0%{opacity:0} 20%{opacity:1} 60%{opacity:1} 100%{opacity:0} } 

如果文本页面使用“myblink”标签,则在文本页面和(无CSS)页面之间循环的testing将会崩溃。

我卑微的假设是:

[活跃webkitanimation解构] + [下一页重载同时加载] + [运气不好] = [内存损坏]

我说这是因为,我可能会错过一些东西,animation的内容似乎几乎不相关。 我试过了:

  • 使不透明度总是等于1
  • 用位置变换代替不透明度
  • closuresanimation循环
  • 将闪烁标记放在图片上而不是文本上
  • 玩关键帧

…但它总是会崩溃。 唯一能够停止崩溃的是closuresanimation循环,缩短animation持续时间 – 即在页面closures前animation完成,崩溃将停止。

现在我已经通过将游戏中的animation转换为完全基于canvas的解决scheme来解决游戏中的崩溃问题;我知道。 所以我暂时不会进一步调查,但是我仍然很想把它缩小到一个特定的webkit源代码。

附注:我想expression一下:

https://www.codeaurora.org/forums/viewtopic.php?t=450

这是相同的问题或非常相似的东西。

11月19日更新:

原来的服务器已经脱机了,所以把上面的testing代码放在Dropbox中:

https://dl.dropboxusercontent.com/u/56202247/CrashApp.zip https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip

(请注意,CrashApp应用程序中的url必须更改为放置HTML页面的任何位置)

Solutions Collecting From Web of "信号11 SIGSEGV在Galaxy S3 Android WebView中崩溃"

我正在玩你的crashApp。

使用设备; ■SHARP ISW16SH■LG Optimus Vu L-06D(3〜10页不能存活)

这些是我经常得到的错误。 致命信号11(SIGSEGV)dlmalloc中的dlfree HEAP存储器损坏中的HEAP存储器损坏

显然,有一个内存分配或双重释放的问题。 这不是可以解决的问题。 (除非,NDK)我发现的唯一解决scheme是热插拔webview的dynamic。 总是在新创build的webview中加载下一页将防止发生这种情况。 然而,我似乎无法阻止记忆下降。 最终Android会在您的应用程序成长为一个吃怪物的内存时触发。

然后我开始玩两个相同的空活动课。 没有XML。 所以,

 onCreate() {  WebView wv = new WebView(context);  setContentView( wv ); } void onDestroy() {  ViewGroup vg = (ViewGroup)game_wv.getParent();  vg.removeView(game_wv);  destroyWebView( game_wv );  game_wv = null;  super.onDestroy();  System.gc();  //clean up what's freed in webViewLoadComplete (hopefully) } 

我也在onPageFinished中调用了另一个gc,以确保其他活动没有问题。

 public final class WvClient extends WebViewClient {  public void onPageFinished(WebView wv, String url) {    webViewLoadComplete(game_wv);    System.gc();  //clean up the other activity  } } 

这里是destroyWebView和webViewLoadComplete。 我不太确定一些function(如clearAnimation或clearDisappearingChildren)或者什么是正确的调用顺序。 我只是…把所有东西扔在那里。 哈

 void destroyWebView( WebView wv ){  wv.stopLoading(); // wv.pauseTimers();  wv.clearFormData();  wv.clearAnimation();  wv.clearDisappearingChildren();  wv.clearView(); // wv.clearCache( true );  wv.clearHistory(); // wv.clearMatches(); // wv.clearSslPreferences();  wv.destroyDrawingCache();  wv.freeMemory();  wv.destroy(); } void webViewLoadComplete( WebView wv ){ // wv.stopLoading(); // wv.pauseTimers(); // wv.clearFormData();  wv.clearAnimation();  wv.clearDisappearingChildren(); // wv.clearView(); ////wv.clearCache( true ); // wv.clearHistory(); ////wv.clearMatches(); ////wv.clearSslPreferences();  wv.destroyDrawingCache();  wv.freeMemory(); // wv.destroy(); } 

不知何故,它的工作…

认为最终的方法可能是使用NDK?

我通过在HTML页面的HEAD中禁用格式检测来解决了一些低级别的崩溃,包括4.0.4的崩溃(这是Google的朋友提出的):

 <meta name="format-detection" content="telephone=no" /> <meta name="format-detection" content="email=no" /> <meta name="format-detection" content="address=no"/> 

但是,4.1.1更新将这些崩溃带回了S3,我还没有想出一个解决方法。

你不是唯一的这个问题,我一直在谷歌search,看起来像这样的其他人http://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy- s3-only / 77/181155在S3上的股票导航器上有一个HTML 5的bug(来自不同国家的不同的ROM),我试过的每一个S3都崩溃了。 在铬上尝试,它的作品非常漂亮。 我确定股票导航器上有一个错误。

三星设备的内存容量较低,这是一个长期的问题。 没有解决scheme。

我一直有这个问题(或至less非常相似)使用http://fgnass.github.io/spin.js/

当我把它从页面中删除时,没有任何问题。 也似乎发生在Android 4.0和4.1,但不是4.3

我们一直没能find一个解决办法,除了解决它,并find一些比spin.js微调使用的东西。 但绝对看起来像一个Android的问题。 令我感到不快的是,它似乎并没有更为广泛。

与我的情况一样,因为它有点不同,但有相同的症状。 我通过静态variables*维护设备旋转的WebView实例,但是当没有必要时,我的错误是在该实例上调用WebView.restoreState

猥亵代码:

 private static FrameLayout _rootView; @InjectView(R.id.main_webview) WebView _webView; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { boolean inflatingNow = _rootView == null; if (inflatingNow) { Container.Log.d(TAG, "onCreateView: rootView null. Recreating views"); _rootView = (ViewGroup) inflater.inflate(R.layout.fragment_main, container, false); } else { Container.Log.d(TAG, "onCreateView: reusing previousely created views"); ViewHelper.detachFromParent(_rootView); // Detaching from old container } ButterKnife.inject(this, _rootView); // Will assign the _webView variable if (inflatingNow) { configureWebView(_webView); } if (savedInstanceState != null) { _webView.restoreState(savedInstanceState); } return _rootView; } 

固定代码:

 private static FrameLayout _rootView; @InjectView(R.id.main_webview) WebView _webView; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { boolean inflatingNow = _rootView == null; if (inflatingNow) { Container.Log.d(TAG, "onCreateView: rootView null. Recreating views"); _rootView = (ViewGroup) inflater.inflate(R.layout.fragment_main, container, false); } else { Container.Log.d(TAG, "onCreateView: reusing previousely created views"); ViewHelper.detachFromParent(_rootView); // Detaching from old container } ButterKnife.inject(this, _rootView); if (inflatingNow) { configureWebView(_webView); if (savedInstanceState != null) { _webView.restoreState(savedInstanceState); } } return _rootView; } 

*)作为一个方面说明,我认为这是一个很好的方法来减less设备旋转的足迹。 额外的好处是webview保持滚动在用户所在的位置,不需要重新加载页面。 请注意,这种方法意味着你只能在任何给定的活动(单例)中一次使用片段。

个人经验:

我尝试了很多东西,比如不使用RelativeLayout,没有在webview后面绘制很多东西,还有很多东西,正如很多关于这个SIGSEGV 11 Webview问题的StackOverflow文章所解释的。

在4.1版本上发生问题(仅限于?)。

什么对我有效:

  • 我停止使用由RoundRectShape “closures”到WebView的drawables。 也许硬件层和圆angular之间有什么问题?
  • 我停止了在Web视图上的视图(如进度视图)。
  • 我停止做任何事情,将使webview在工作时重新计算布局 。 比如dynamic地在我的屏幕上添加一个视图。

不过,由于其他原因,有时会发生崩溃,大多数情况下,在转到其他活动并返回到WebView时。 在日志中,我可以看到类似“webcoreview:nativeDestroy”的东西,可能意味着某些东西似乎被某个人使用之后使用。 然后出现SIGSEGV 11。

但至less,发生的次数要less得多。