信号11 SIGSEGV崩溃银河S3的Android的WebView [英] Signal 11 SIGSEGV Crash in Galaxy S3 Android WebView
问题描述
我有一个Android的WebView一个复杂的，互动的HTML5 - 它工作正常，除了银河S3基本上所有的平台。银河S3（安卓4.0.4），一旦出了每5倍左右，加载完成后立即，/system/lib/libwebcore.so试图访问无效的内存和一个致命的信号11（SIGSEGV）在[各个地址（code = 1）被抛出。
HTML5的是一个很小的战斗的敌人在哪里出现，用户斜线他们继续。在战役之间是正常的HTML页面：正常的页面 - > HTML5战 - >正常的页面 - > HTML5战 - >正常的页面 - > HTML5的战斗。 HTML5的没有做什么特别的即装即用的 - 有很多的-webkit-动画来电...
.enemy {
位置：绝对的;
不透明度：0;
-webkit-动画：enemyAnim 0.6秒线性0.2秒;
}
...引用了大量的-webkit-关键帧...
@ - WebKit的关键帧enemyAnim {
从 {
-webkit-变换：矩阵（1，0，0，1，144.25，150.25），规模（1，1）;
不透明度：1;
}
8.33％{
-webkit-变换：矩阵（1，0，0，1，189.406，102.206）规模（1.3066，1.3066）;
不透明度：1;
}
16.66％{
-webkit-变换：矩阵（1，0，0，1，200.424，82.649）规模（1.414，1.414）;
不透明度：1;
}
/ * ... * /
和一个相当复杂的股利树，但没有什么特别的实验。还有的JavaScript的一些水平，但挂起甚至出现了所有关闭JavaScript的发生。
有没有人有一个问题，一个银河S3是...有什么不同？没有一款Android 2.x设备有这个问题，甚至是Galaxy Nexus的运行4.1.1似乎并没有什么特别的问题。我从来没有被诱惑写溢出之前，堆栈，但是这是真的伤脑筋我...
在搜索上的Android的WebView SIGSEGV崩溃＆放大器; 4.0.4的WebView SIGSEGV崩溃给出了几个问题，但是：
-
webview.clearCache（）/ webView.destroyDrawingCache（）似乎并没有产生效果（尽管这个坑显然是内存问题，添加/删除的System.gc（）S在不同的地方有没有很大的结果） 信号11 SIGSEGV崩溃的Android
-
有没有用帆布作为 <一href="http://stackoverflow.com/questions/10989120/very-strange-crash-drawing-on-canvas-on-android-4-0-3-a-libc-fatal-signal-11">Very奇怪的崩溃借鉴Android上4.0.3画布 - ＆GT; A / libc中：致命信号11（SIGSEGV） （是的，我知道 - 调用此页面HTML5是一个有点夸张）
-
有没有使用ClearView的（）作为在 <一href="http://stackoverflow.com/questions/12261523/execute-webview-loadurl-after-webview-clearview-multitimes-will-cause-crash">execute WebView.loadurl（）Webview.clearView后（）multitimes会引起死机
-
有没有使用preserve-3D的作为 <一href="http://$c$c.google.com/p/android/issues/detail?id=16563">http://$c$c.google.com/p/android/issues/detail?id=16563
-
我看着变更为Android的WebKit查找可疑补丁4.0.4后，以为我有什么用下面，但是生根S3并考虑到4.1.1没有解决的问题： <一href="https://github.com/teamgummy/android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f66a8b17c3d06">https://github.com/teamgummy/android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f66a8b17c3d06
由于一些崩溃的记忆过程中存在的free（）的S，我知道事情正在free'd周围的崩溃之时，我的直觉是，有些事情正在释放中端渲染不应该是。这是令人沮丧，因为SIGSEGVs应与纯HTML，JS，和放大器物理上不可能; CSS = /
下面是一个简单的崩溃报告。需要注意的是崩溃位置不限于以下;崩溃报告似乎并没有成为很大的不同，但似乎有在的位置有些变化。
10-08 17：34：06.605：I / DEBUG（524）：*** *** *** *** *** *** *** * ** *** *** *** *** *** *** *** ***
10-08 17：34：06.605：I / DEBUG（524）：建立指纹：三星/ m0xx / M0：4.0.4 / IMM76D / I9300XXBLH1：用户/释放键
10-08 17：34：06.605：I / DEBUG（524）：PID：7443，TID：7443＆GT;＆GT;＆GT; cool.tiny.rpg.battle＆LT;＆LT;＆LT;
10-08 17：34：06.605：I / DEBUG（524）：11（SIGSEGV），code 1（SEGV_MAPERR），故障地址deadbaad
10-08 17：34：06.605：I / DEBUG（524）：R0 deadbaad R1 R2 00000001 40000000 00000000 R3
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 43430000亿
10-08 17：34：06.605：I / DEBUG（524）：D2 D3 43b6800041a00000 41a8000043020000
10-08 17：34：06.610：I / DEBUG（524）：D4八千万亿D5 43aa00003f800000
10-08 17：34：06.610：I / DEBUG（524）：D6 D7 43a4000043430000 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 0000000000000000 D11
10-08 17：34：06.610：I / DEBUG（524）：D12 D13 0000000000000000 0000000000000000
10-08 17：34：06.610：I / DEBUG（524）：D14 D15 0000000000000000 0000000000000000
10-08 17：34：06.610：I / DEBUG（524）：D16 40768000亿D17 7e37e43c8800759c
10-08 17：34：06.610：I / DEBUG（524）：D18 D19 0000000000000000 0000000000000000
10-08 17：34：06.610：I / DEBUG（524）：D20 3ff0000000000000 D21八千万亿
10-08 17：34：06.610：I / DEBUG（524）：D22 0000000000000000 0000000000000000 D23
10-08 17：34：06.610：I / DEBUG（524）：D24 0000000000000000 D25 3ff0000000000000
10-08 17：34：06.610：I / DEBUG（524）：D26 40340000亿D27 3ff0000000000000
10-08 17：34：06.610：I / DEBUG（524）：D28 D29 0000000000000000 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件000179c8 /system/lib/libc.so
10-08 17：34：06.750：I / DEBUG（524）：＃01件00013852 /system/lib/libc.so
10-08 17：34：06.750：I / DEBUG（524）：＃02件00015b90 /system/lib/libc.so（dlfree）
10-08 17：34：06.750：I / DEBUG（524）：＃03件00016208 /system/lib/libc.so（免费）
10-08 17：34：06.750：I / DEBUG（524）：＃04件0010f79c /system/lib/libwebcore.so（_Z6yyfreePvS_）
10-08 17：34：06.750：I / DEBUG（524）：＃05件0010ef70 /system/lib/libwebcore.so
10-08 17：34：06.750：I / DEBUG（524）：＃06件003ee8ec /system/lib/libwebcore.so
10-08 17：34：06.755：I / DEBUG（524）：＃07件003eef44 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD1Ev）
10-08 17：34：06.755：I / DEBUG（524）：＃08件003eef84 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD0Ev）
10-08 17：34：06.755：I / DEBUG（524）：＃09件0019b2ca /system/lib/libwebcore.so
10-08 17：34：06.755：I / DEBUG（524）：＃10件003ec6a0 /system/lib/libwebcore.so（_ZN5Layer14removeChildrenEv）
10-08 17：34：06.755：I / DEBUG（524）：＃11件003ec782 /system/lib/libwebcore.so（_ZN5LayerD2Ev）
10-08 17：34：06.760：I / DEBUG（524）：＃12件003eef70 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD1Ev）
10-08 17：34：06.760：I / DEBUG（524）：＃13件003eef84 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD0Ev）
10-08 17：34：06.760：I / DEBUG（524）：＃14件0019b2ca /system/lib/libwebcore.so
10-08 17：34：06.760：I / DEBUG（524）：＃15件003ec6a0 /system/lib/libwebcore.so（_ZN5Layer14removeChildrenEv）
10-08 17：34：06.760：I / DEBUG（524）：＃16件003ec782 /system/lib/libwebcore.so（_ZN5LayerD2Ev）
10-08 17：34：06.760：I / DEBUG（524）：＃17件003eef70 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD1Ev）
10-08 17：34：06.760：I / DEBUG（524）：＃18件003eef84 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD0Ev）
10-08 17：34：06.760：I / DEBUG（524）：＃19件0019b2ca /system/lib/libwebcore.so
10-08 17：34：06.760：I / DEBUG（524）：＃20件003ec6a0 /system/lib/libwebcore.so（_ZN5Layer14removeChildrenEv）
10-08 17：34：06.765：I / DEBUG（524）：＃21件003ec782 /system/lib/libwebcore.so（_ZN5LayerD2Ev）
10-08 17：34：06.765：I / DEBUG（524）：＃22件003eef70 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD1Ev）
10-08 17：34：06.765：I / DEBUG（524）：＃23件003eef84 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD0Ev）
10-08 17：34：06.765：I / DEBUG（524）：＃24件0019b2ca /system/lib/libwebcore.so
10-08 17：34：06.765：I / DEBUG（524）：＃25件003ec6a0 /system/lib/libwebcore.so（_ZN5Layer14removeChildrenEv）
10-08 17：34：06.765：I / DEBUG（524）：＃26件003ec782 /system/lib/libwebcore.so（_ZN5LayerD2Ev）
10-08 17：34：06.765：I / DEBUG（524）：＃27件003eef70 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD1Ev）
10-08 17：34：06.765：I / DEBUG（524）：＃28件003eef84 /system/lib/libwebcore.so（_ZN7WebCore12LayerAndroidD0Ev）
10-08 17：34：06.770：I / DEBUG（524）：＃29件0019b2ca /system/lib/libwebcore.so
10-08 17：34：06.770：I / DEBUG（524）：＃30件003ec6a0 /system/lib/libwebcore.so（_ZN5Layer14removeChildrenEv）
10-08 17：34：06.770：I / DEBUG（524）：＃31件003ec782 /system/lib/libwebcore.so（_ZN5LayerD2Ev）
10-08 17：34：06.770：I / DEBUG（524）：约地址deadbaad内存映射：
10-08 17：34：06.770：I / DEBUG（524）：bed4a000-bed6b000 [堆栈]
10-08 17：34：06.770：I / DEBUG（524）：（没有地图的地址）
10-08 17：34：06.770：I / DEBUG（524）：FFFF0000-ffff1000 [载体]
10-08 17：34：06.770：I / DEBUG（524）：堆栈：
10-08 17：34：06.770：I / DEBUG（524）：bed6a270 00000001
10-08 17：34：06.770：I / DEBUG（524）：bed6a274 bed6a2b0 [堆栈]
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 [堆栈]
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 [堆]
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 [堆栈]
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 [堆栈]
10-08 17：34：06.775：I / DEBUG（524）：bed6a2c4 fffffbdf
10-08 17：34：06.775：I / DEBUG（524）：bed6a2c8 bed6a2dc [堆栈]
10-08 17：34：06.775：I / DEBUG（524）：bed6a2cc bed6a2dc [堆栈]
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的标记堆栈（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2e4 474e4954的/ dev / ashmem / Dalvik的堆（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2e8 4e49203a的/ dev / ashmem / Dalvik的堆（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2ec 494c4156的/ dev / ashmem / Dalvik的堆（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2f0 45482044的/ dev / ashmem / Dalvik的堆（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2f4 41205041的/ dev / ashmem / Dalvik的堆（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2f8 45524444的/ dev / ashmem / Dalvik的堆（删除）
10-08 17：34：06.775：I / DEBUG（524）：bed6a2fc 49205353的/ dev / ashmem / Dalvik的堆（删除）
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 [堆]
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 [堆]
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 [堆]
10-08 17：34：06.775：I / DEBUG（524）：bed6a354 400e7550
10-08 17：34：06.775：I / DEBUG（524）：bed6a358 01f74458 [堆]
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 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a36c 00000000
10-08 17：34：06.780：I / DEBUG（524）：bed6a370 bed6a584 [堆栈]
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 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a37c 020d499c [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a380 000097a0 /系统/斌/ app_process
10-08 17：34：06.780：I / DEBUG（524）：bed6a384 00004000
10-08 17：34：06.780：I / DEBUG（524）：bed6a388 01d087b8 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a38c 400e7560
10-08 17：34：06.780：I / DEBUG（524）：bed6a390 01dc6ef8 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a394 400e7528
10-08 17：34：06.780：I / DEBUG（524）：bed6a398 01fd5378 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a39c 400e7580
10-08 17：34：06.780：I / DEBUG（524）：bed6a3a0 01ddafa8 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a3a4 01ddb008 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a3a8 01ed4568 [堆]
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 [堆]
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 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a3d0 01fa7160 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a3d4 01fd7d2c [堆]
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的堆（删除）
10-08 17：34：06.780：I / DEBUG（524）：bed6a3e0 01fa7158 [堆]
10-08 17：34：06.780：I / DEBUG（524）：bed6a3e4 01fd7d2c [堆]
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：
我还有很长的路要走缩小下来到一个简单的测试案例，但我已经得到了再现上述SIGSEGV的下降，从一个普通的WebView应用程序加载2的HTML页面。 web视图简单地启动和加载：
<一个href="http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html">http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html
本页面链接到对方，不一定崩溃的第一个观点，但他们最终崩溃100％在Android 4.1.1模拟器和我的Galaxy Nexus的（4.1.1）。请注意，文章的标题是错误的 - 这肯定不是S3不仅
有趣的是，
- 使用的WebView在我真正的应用程序，加载1页（crash.html或任何重HTML5页）多次就足以引起SIGSEGV
。
- 使用测试这个简单的web视图的应用程序，将两页需要对方崩溃 - 只是重复装载1页不会死
。
- 加载在Android 4.1.1网页浏览器的网页，甚至是2页是不够的 - 它会死，但它需要多页
在错误位置而言，也有在HTMLImageElement有关析构函数的崩溃不同的堆栈跟踪，一些相关的样式表，等等。安卓2.X，iOS的，任何其他浏览器是坚如磐石的。
Javascript的改变DOM，这似乎足以在这里引起崩溃了...但是为什么呢？
乍一看，这在我看来是一个垃圾收集的问题 - 我的应用程序将垃圾收集早于普通的WebView应用程序，因为它已经在其他地方使用更多的内存。我没有收到内存错误消息，但是。我会继续努力缩小这个下来，但任何人任何想法，应该如何进行或可能是什么问题，确实有我永恒不灭的亲情。
测试应用程序code：
<一个href="http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip">http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip
测试应用程序APK：
<一个href="http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk">http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk
所有的HTML资源：
<一个href="http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip">http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip
测试应用程序的启动code：
公共类MainActivity延伸活动{
私人的WebView web视图;
公共无效的onCreate（包savedInstanceState）{
super.onCreate（savedInstanceState）;
的setContentView（R.layout.activity_main）;
web视图=（web视图）findViewById（R.id.webView1）;
webView.getSettings（）setJavaScriptEnabled（真）。
webView.setWebViewClient（新WebViewClient（））;
webView.setWebChromeClient（新WebChromeClient（））;
webView.loadUrl（http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/crash.html）;
}
}
更新2月3日：
这个问题似乎发生是由于WebKit的动画的页面关闭时仍在动画。我缩小了一次碰撞到一个单一的myblink的标签：
<$p$p><$c$c>.myblink{-webkit-animation-name:"anime-blink";-webkit-animation-duration:1.2s;-webkit-animation-timing-function:ease-in-out;-webkit-animation-iteration-count:infinite} @ -webkit-关键帧动漫眨眼{0％{不透明度：0} 20％{不透明度：1} 60％{不透明度：1} 100％{不透明度：0} }一个测试文本页面和一个（不CSS）的画布页面之间循环会会崩溃当且仅当在文字页中使用的myblink标签。
我卑微的假设是：
[拆解主动WebKit的动画] + [重下页加载在同一时间] + [厄运时间] = [内存损坏]
我这样说是因为，我可能会失去了一些东西，动画的内容看起来几乎毫无关系。我想：
- 使混浊总是等于1
- 在一个位置取代不透明变换
- 关闭动画循环
- 将文本的闪烁标签上的图片，而不是
- 在使用关键帧玩弄
...但它总是会崩溃。这将阻止崩溃的唯一的事情就是关闭动画循环，也缩短动画持续时间 - 如果动画结束的页面被关闭前，即崩溃将停止
现在我已经在游戏中的碰撞各地通过将游戏中的动画，以一个完全基于canvas的解决方案工作; ^^破釜沉舟，我知道了。所以，我不会深入研究了一段时间，但我仍然会这么爱来缩小下来到一个特定的一块的WebKit源$ C $ C。
附注：我想给一个shoutout为：
<一个href="https://www.$c$caurora.org/forums/viewtopic.php?t=450">https://www.$c$caurora.org/forums/viewtopic.php?t=450
...，要么是同一个问题或非常类似的东西。
更新11月19日：
原服务器脱机，所以已经把上面的测试code在Dropbox的：
<一个href="https://dl.dropboxusercontent.com/u/56202247/CrashApp.zip">https://dl.dropboxusercontent.com/u/56202247/CrashApp.zip <一href="https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip">https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip
（注意，URL中CrashApp应用程序已被改变，无论你把HTML页面）
我跟你crashApp玩弄。
使用设备; ■夏普ISW16SH ■LG擎天柱武L-06D（不能在3〜10页甚至生存）
这些都是我经常有错误。 致命的信号11（SIGSEGV） 堆内存损坏IN dlfree 堆内存损坏IN dlmalloc
显然，有一个内存分配或双释放问题。而这不是一朝一夕所能解决。 （除非，NDK） 我发现的唯一的解决办法是热插拔飞web视图。 始终加载下一个页面，在新创建的WebView将prevent这种情况的发生。 不过，我似乎无法掉落停止内存。最终，Android将罢工一旦你的应用程序成长为一个吃内存的怪物。
然后，我开始有两个相同的空活动类播放。 没有XML。 因此，
的onCreate（）{
的WebView WV =新的WebView（上下文）;
的setContentView（WV）;
}
无效的onDestroy（）{
ViewGroup中VG =（ViewGroup中）game_wv.getParent（）;
vg.removeView（game_wv）;
destroyWebView（game_wv）;
game_wv = NULL;
super.onDestroy（）;
System.gc（）的; //清理什么的释放在webViewLoadComplete（希望）
}
我也叫了onPageFinished另一个GC只是为了确保其他活动是一去不复返了。
公开最后一类WvClient扩展WebViewClient {
公共无效onPageFinished（web视图WV，字符串URL）{
webViewLoadComplete（game_wv）;
System.gc（）的; //清理其他活动
}
}
这里的destroyWebView和webViewLoadComplete。 我不是很确定一些功能（如clearAnimation或clearDisappearingChildren），或者什么是正确的顺序调用。 我只是...在那里把一切。哈哈
无效destroyWebView（的WebView WV）{
wv.stopLoading（）;
// wv.pauseTimers（）;
wv.clearFormData（）;
wv.clearAnimation（）;
wv.clearDisappearingChildren（）;
wv.clearView（）;
// wv.clearCache（真正的）;
wv.clearHistory（）;
// wv.clearMatches（）;
// wv.clearSsl preferences（）;
wv.destroyDrawingCache（）;
wv.freeMemory（）;
wv.destroy（）;
}
无效webViewLoadComplete（的WebView WV）{
// wv.stopLoading（）;
// wv.pauseTimers（）;
// wv.clearFormData（）;
wv.clearAnimation（）;
wv.clearDisappearingChildren（）;
// wv.clearView（）;
//// wv.clearCache（真正的）;
// wv.clearHistory（）;
//// wv.clearMatches（）;
//// wv.clearSsl preferences（）;
wv.destroyDrawingCache（）;
wv.freeMemory（）;
// wv.destroy（）;
}
不知何故，它的工作...
想到的最终方法可能会使用NDK？
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.
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;
}
…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;
}
/*…*/
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.
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...
Searching on "Android WebView sigsegv crash" & "4.0.4 WebView sigsegv crash" gives several issues, but:
webview.clearCache()/webView.destroyDrawingCache() don't seem to have an effect (though this hang is clearly a memory issue, adding/removing System.gc()s in various places had no great result) SIGNAL 11 SIGSEGV crash Android
There's no use of canvas as in Very 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)
There's no use of clearView() as in execute WebView.loadurl() after Webview.clearView() multitimes will cause crash
There's no use of preserve-3d as in http://code.google.com/p/android/issues/detail?id=16563
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
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
Update Nov 30th:
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
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.
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.
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 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.
Test App Code:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip
Test App APK:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk
All HTML resources:
http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip
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");
}
}
Update Feb 3rd:
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}
}
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.
My humble hypothesis is:
[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:
- making opacity always equal 1
- replacing opacity with a position transform
- turning off animation looping
- putting the blink tag on a picture instead of text
- playing around with keyframes
…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.
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.
Side note: I'd like to give a shoutout to:
https://www.codeaurora.org/forums/viewtopic.php?t=450
...which is either the same issue or something very similar.
Update Nov 19th:
The original server was taken offline, so have placed the above test code in Dropbox:
https://dl.dropboxusercontent.com/u/56202247/CrashApp.zip https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.zip
(Note that url in CrashApp application has to be changed to wherever you put the HTML pages)
I was playing around with your crashApp.
Using devices; ■ SHARP ISW16SH ■ LG optimus Vu L-06D (can't even survive after 3 ~ 10 pages)
These are the error that I often got. Fatal signal 11 (SIGSEGV) HEAP MEMORY CORRUPTION IN dlfree HEAP MEMORY CORRUPTION IN dlmalloc
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.
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)
}
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
}
}
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...
Think the ultimate method might be using a NDK?
这篇关于信号11 SIGSEGV崩溃银河S3的Android的WebView的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
