Galaxy S3 Android WebView 中的 Signal 11 SIGSEGV 崩溃 [英] Signal 11 SIGSEGV Crash in Galaxy S3 Android WebView
问题描述
我在 Android WebView 中有一个复杂的交互式 HTML5 - 它基本上可以在除 Galaxy S3 之外的所有平台上正常工作.在 Galaxy S3 (Android 4.0.4) 上，每 5 次左右，就在加载完成后，/system/lib/libwebcore.so 尝试访问无效内存和位于 [各种地址的致命信号 11 (SIGSEGV)] (code=1) 被抛出.
I have a complex, interactive HTML5 in an Android WebView - and it works fine on basically all platforms except Galaxy S3. On Galaxy S3 (Android 4.0.4), once out of every 5 times or so, just after the load completes, /system/lib/libwebcore.so tries to access invalid memory and a Fatal signal 11 (SIGSEGV) at [various addresses] (code=1) is thrown.
HTML5 是一场小规模的战斗，敌人会出现，用户砍杀他们以继续战斗.在战斗之间是普通的 html 页面:普通页面 -> HTML5 战斗 -> 普通页面 -> HTML5 战斗 -> 普通页面 -> HTML5 战斗.HTML5 没有做任何特别开箱即用的事情 - 有很多 -webkit-animation 调用......
The HTML5 is a tiny battle where enemies appear and the user slashes them to proceed. In between battles are normal html pages: normal page -> HTML5 battle -> normal page -> HTML5 battle -> normal page -> HTML5 battle. The HTML5 doesn't do anything particularly out-of-the-box - there's a lot of -webkit-animation calls...
.enemy {
position:absolute;
opacity:0;
-webkit-animation:enemyAnim 0.6s linear 0.2s;
}
...引用了很多 -webkit-keyframes...
…that reference a lot of -webkit-keyframes...
@-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，但即使关闭所有 Javascript 也会出现挂起.
And a fairly complex div tree, but nothing particularly experimental. There's some level of Javascript, but the hangs appear to occur even with all Javascript turned off.
有没有人对 Galaxy S3 的...与众不同有意见?没有 Android 2.x 设备有这个问题，甚至运行 4.1.1 的 Galaxy Nexus 似乎也没有任何特别的问题.我以前从未想过要写信给 Stack Overflow，但这真的让我很烦恼……
Has anyone ever had a problem with a Galaxy S3 being…different? No Android 2.x devices have this problem, and even a Galaxy Nexus running 4.1.1 doesn't seem to have any particular problem. I've never been tempted to write to Stack Overflow before, but this is really vexing me...
搜索Android WebView sigsegv crash"&4.0.4 WebView sigsegv crash"给出了几个问题，但是:
Searching on "Android WebView sigsegv crash" & "4.0.4 WebView sigsegv crash" gives several issues, but:
webview.clearCache()/webView.destroyDrawingCache() 似乎没有效果(尽管这个挂起显然是内存问题，在各个地方添加/删除 System.gc() 并没有什么好处结果)SIGNAL 11 SIGSEGV 崩溃 Android
没有像在Android 4.0.3 上画布上的奇怪崩溃绘图.A/libc: 致命信号 11 (SIGSEGV)(是的，我知道 - 将此页面称为 HTML5 有点牵强)
There's no use of canvas as in Strange crash drawing on canvas on Android 4.0.3. A/libc: Fatal signal 11 (SIGSEGV) (Yes I know - calling this page HTML5 is a bit of a stretch)
没有使用 clearView()在 Webview.clearView() 之后执行 WebView.loadurl()多次会导致崩溃
There's no use of clearView() as in execute WebView.loadurl() after Webview.clearView() multitimes will cause crash
没有使用 preserve-3d，如http://code.google.com/p/android/issues/detail?id=16563
There's no use of preserve-3d as in http://code.google.com/p/android/issues/detail?id=16563
我查看了 android webkit 的更改列表，寻找 4.0.4 之后的可疑修复，并认为我有以下问题，但是将 S3 植根并将其带到 4.1.1 并没有解决问题:https://github.com/teamgummy/android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f>
I looked at the changelist for android webkit looking for suspicious fixes after 4.0.4, and thought I had something with the below, but rooting the S3 and taking it to 4.1.1 didn't fix the issue: https://github.com/teamgummy/android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f66a8b17c3d06
由于在 memory free()s 期间发生了一些崩溃，我知道在崩溃发生时某些东西正在被释放，我的直觉是有些东西在渲染中被释放，而这不应该是.这很令人沮丧，因为 SIGSEGV 在物理上对于纯 HTML、JS 和 & 来说是不可能的.CSS =/
Since some of the crashes are occuring during memory free()s, I know that things are being free'd around the time of the crash and my gut feeling is that some things are being freed mid-render that shouldn't be. It's frustrating because SIGSEGVs should be physically impossible with pure HTML, JS, & CSS =/
以下是示例崩溃报告.请注意，崩溃位置不限于以下；崩溃报告似乎并没有太大的不同，但位置似乎有所不同.
Below is a sample crash report. Note that the crash location is not limited to the below; crash reports don't seem to be wildly different but there seems to be some variation in location.
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 日更新:
Update Nov 30th:
在将其缩小到一个简单的测试用例方面还有很长的路要走，但我已经将上述 SIGSEGV 复制到从普通 webview 应用程序加载的 2 个 HTML 页面.webview 只是启动并加载:
I've still got a long way to go in narrowing this down to a simple test case, but I've gotten reproduction of the above SIGSEGV down to 2 HTML pages loaded from a plain webview app. The webview simply starts up and loads:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html
页面相互链接，不一定在第一次查看时崩溃，但最终它们在 Android 4.1.1 模拟器和我的 Galaxy Nexus (4.1.1) 上崩溃 100%.请注意，帖子标题是错误的 - 这肯定不仅仅是 S3.
The pages link to each other, and don't necessarily crash on the first view, but eventually they crash 100% on the Android 4.1.1 emulator and my Galaxy Nexus (4.1.1). Note that the post title is wrong - this definately isn't S3 only.
有趣的是，
- 在我的真实应用程序中使用 webview，重复加载 1 个页面(crash.html 或任何繁重的 HTML5 页面)足以导致 SIGSEGV.
- 使用这个普通的 webview 应用程序进行测试，两个页面需要相互崩溃 - 只是重复加载 1 个页面不会死.
- 在 Android 4.1.1 网页浏览器中加载页面，即使 2 个页面也不够 - 它会死，但需要很多页面.
The interesting thing is,
- Using the webview inside my real app, loading 1 page (crash.html or any heavy HTML5 page) repeatedly is enough to cause the SIGSEGV.
- Using this plain webview app for testing, the two pages need each other to crash - just loading 1 page repeatedly will not die.
- Loading the pages in the Android 4.1.1 web browser, even the 2 pages aren't enough - it will die but it takes many pages.
在错误位置方面，崩溃有不同的堆栈跟踪，一些与样式表有关，另一些与 HTMLImageElement 的析构函数有关.Android 2.x、iOS、任何其他浏览器都坚如磐石.
In terms of error location, there are different stack traces on the crashes, some related to stylesheets, others related to destructors at HTMLImageElement. Android 2.x, iOS, any other browser is rock solid.
Javascript 更改了 DOM，这似乎足以导致此处崩溃……但为什么呢?
乍一看，这让我觉得这是一个垃圾收集问题——我的应用程序会比普通的 webview 应用程序更早地进行垃圾收集，因为它在其他地方使用了更多内存.但是，我没有收到内存错误消息.我将继续努力缩小范围，但任何对如何进行或可能是什么问题有任何想法的人都会真正拥有我永恒不渝的感情.
Javascript changes the DOM, and that appears to be enough to cause the crash here…but why?
At first glance this strikes me as a garbage collection problem - my app would garbage collect earlier than the plain webview app because it has used more memory in other places. I'm not getting memory error messages, however. I'll continue working to narrow this down, but anyone with any ideas as to how to proceed or what might be the issue truly has my eternal undying affection.
测试应用代码:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip
测试应用 APK:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk
所有HTML资源:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip
测试App的启动代码:
Test App's startup code:
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 日更新:
这个问题似乎是由于页面关闭时 webkit-animations 仍在动画中造成的.我将一次崩溃缩小到一个myblink"标签:
The problem seems to occur due to webkit-animations that are still animating when the page closes. I narrowed down one crash to a single "myblink" tag:
.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)画布页面之间循环的测试会崩溃.
A test that cycled between a text page and a (no-CSS) canvas page would would crash if and only if the text page used the "myblink" tag.
我的谦虚假设是:
[活动 webkit-animation 的解构器] + [同时加载大量下一页] + [时机不好] = [内存损坏]
[deconstructor for active webkit-animation] + [heavy next page being loaded at same time] + [bad luck with timing] = [memory corruption]
我这样说是因为，我可能会遗漏一些东西，动画的内容似乎几乎无关紧要.我试过了:
I say this because, and I could be missing something, the contents of the animation seem almost irrelevant. I tried:
- 使不透明度始终等于 1
- 用位置变换替换不透明度
- 关闭动画循环
- 将闪烁标签放在图片而不是文字上
- 玩转关键帧
……但它总是会崩溃.唯一可以阻止崩溃的是关闭动画循环并缩短动画持续时间 - 即如果动画在页面关闭之前完成，崩溃将停止.
…but it would always crash. The only thing that would stop the crashing was to turn off animation looping and also shorten the animation-duration - i.e. crashing would stop if the animation was finished before the page was closed.
目前，我通过将游戏内动画转换为完全基于画布的解决方案来解决游戏中的崩溃问题；^^ 我知道这很激烈.所以我暂时不会进一步调查，但我仍然很乐意将其缩小到特定的 webkit 源代码.
For now I've worked around the crash in-game by converting in-game animations to a completely canvas-based solution ;^^ Drastic, I know. So I won't be investigating further for a while, but still I would so love to narrow this down to a specific piece of webkit source code.
旁注:我想大声疾呼:
https://www.codeaurora.org/forums/viewtopic.php?t=450
...这是相同的问题或非常相似的问题.
...which is either the same issue or something very similar.
11 月 19 日更新:
Update Nov 19th:
原来的服务器下线了，所以把上面的测试代码放到了Dropbox里:
The original server was taken offline, so have placed the above test code in Dropbox:
https://dl.dropboxusercontent.com/u/56202247/CrashApp.ziphttps://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip
(请注意，CrashApp 应用程序中的 url 必须更改为您放置 HTML 页面的位置)
(Note that url in CrashApp application has to be changed to wherever you put the HTML pages)
推荐答案
我在玩你的 crashApp.
I was playing around with your crashApp.
使用设备；■ 夏普ISW16SH■ LG 擎天柱 Vu L-06D(3~10 页后甚至无法生存)
Using devices; ■ SHARP ISW16SH ■ LG optimus Vu L-06D (can't even survive after 3 ~ 10 pages)
这些是我经常遇到的错误.致命信号 11 (SIGSEGV)dlfree 中的堆内存损坏dlmalloc 中的堆内存损坏
These are the error that I often got. Fatal signal 11 (SIGSEGV) HEAP MEMORY CORRUPTION IN dlfree HEAP MEMORY CORRUPTION IN dlmalloc
显然，存在内存分配或双重释放问题.这不是可以修复的.(除非，NDK)我发现的唯一解决方案是即时热交换 webview.始终在新创建的 web 视图中加载下一页将防止这种情况发生.但是，我似乎无法阻止记忆下降.最终，一旦你的应用成长为一个吃内存的怪物，Android 就会出击.
Obviously, there's a memory allocation or double freeing problem. And it's not something that can be fix. (unless, NDK) the only solution I found is to hot-swap the webview on the fly. Always load the next page in the newly created webview will prevent this from happening. however, I can't seem to stop memory from dropping. Eventually Android will strike once your app grows into a memory eating monster.
然后我开始玩两个相同的空活动类.没有 xml.所以，
I then start playing with two identical empty activity class. no xml. so,
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，以确保其他活动永远消失.
I also called another gc in the onPageFinished just to make sure the other activity is gone for good.
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.我不太确定某些函数(如 clearAnimation 或 clearDisappearingChildren)或调用的正确顺序是什么.我只是……把所有东西都扔进去了.哈哈
here's the destroyWebView and webViewLoadComplete. I'm not so sure about some of the functions (like clearAnimation or clearDisappearingChildren) or what's the right order to call. I just... threw everything in there. ha
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();
}
不知何故，它起作用了......
somehow, it worked...
认为最终的方法可能是使用 NDK?
Think the ultimate method might be using a NDK?
这篇关于Galaxy S3 Android WebView 中的 Signal 11 SIGSEGV 崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
