1. 首页
  2. 问答
  3. Signal 11 SIGSEGV在Galaxy S3中崩溃Android WebView

Signal 11 SIGSEGV在Galaxy S3中崩溃Android WebView

2012-10-11 36 views
26

我在Android WebView中有一个复杂的交互式HTML5 - 它基本上在除Galaxy S3以外的所有平台上工作正常。在Galaxy S3（Android 4.0.4）中，每5次左右出现一次，加载完成后，/ system/lib/libwebcore.so会尝试访问无效内存，并在[各个地址中访问致命信号11（SIGSEGV） ]（代码= 1）被抛出。Signal 11 SIGSEGV在Galaxy S3中崩溃Android WebView

HTML5是一个小小的战斗，敌人出现并且用户将其跳过继续。在战斗之间是正常的html页面：普通页面 - > HTML5战斗 - >普通页面 - > HTML5战斗 - >普通页面 - > HTML5战斗。 HTML5的没有做什么特别出的现成 - 有很多-webkit动画的呼叫：

.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，但即使关闭所有Javascript，挂起也会出现。

有人曾经有一个银河S3正在......不同的问题吗？没有Android 2.x设备存在这个问题，即使是运行4.1.1的Galaxy Nexus似乎也没有任何问题。我从来没有想写溢出之前叠加，但是这实在是伤脑筋我...

搜索上的“Android的WebView SIGSEGV崩溃” &“4.0.4的WebView SIGSEGV撞车”给出了一些问题，但：

由于一些崩溃的免费存储过程中存在的（）S，我知道事情正在free'd周围的崩溃之时，我的直觉是，一些东西被释放中旬渲染不应该是。这很令人沮丧，因为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：

我还有很长的路要走缩小下来到一个简单的测试用例去，但我已经得到了上面的SIGSEGV的再现下降到2个HTML页面从一个普通的webview应用程序加载。 web视图只是启动和加载：

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

的页面链接到对方，而不要在第一种观点必然崩溃，但最终他们在Android 4.1.1仿真器和崩溃100％我Galaxy Nexus（4.1.1）。请注意，帖子标题是错误的 - 这绝对不是S3。

有趣的是，
- 在我的真实应用程序中使用webview，反复加载1页（crash.html或任何繁重的HTML5页面）足以导致SIGSEGV。
- 使用这个简单的webview应用程序进行测试，两个页面需要彼此崩溃 - 只需重复加载1页面不会死。
- 在Android 4.1.1网页浏览器中加载页面，即使是2页也不够 - 它会死掉，但会占用很多页面。

就错误位置而言，崩溃时存在不同的堆栈跟踪，一些与样式表相关，另一些与HTMLImageElement的析构函数相关。 Android 2.x，iOS，任何其他浏览器都很稳定。

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

测试应用程序代码：

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

试验A PP的启动代码：

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的动画出现。我缩小一个碰撞到一个单一的“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} 
}

一个文本页和（无CSS）的画布页之间循环测试当且仅当使用的文本页面会会崩溃“ myblink“标签。

我卑微的假设是：

[解构主动WebKit的动画] + [重下一个页面加载在同一时间] + [厄运时序] = [内存损坏]

我说这是因为，我可能会错过一些东西，动画的内容似乎几乎无关紧要。我想：

  • 使混浊总是等于1
  • 与位置替换不透明变换
  • 关闭动画循环
  • 把闪烁标签上的图片代替文字
  • 使用关键帧玩弄

...但它总是会崩溃。停止崩溃的唯一方法是关闭动画循环，并缩短动画持续时间 - 即如果动画在页面关闭之前完成，则崩溃将停止。

现在我已经通过将游戏内动画转换为完全基于画布的解决方案来解决游戏中的崩溃问题; ^^ Drastic，我知道。所以我暂时不会进一步调查，但我仍然很想将其缩小到一个特定的webkit源代码片段。

附注：我想给一个大喊答题节目环节到：

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

...要么是同一个问题或非常类似的东西。

更新11月19日：

原始服务器脱机的，所以已经把上面的测试代码中的Dropbox：

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

（注意CrashApp应用程序，URL必须是更改为你把HTML页面放在哪里）

来源

2012-10-11 John Abrehamson

+0

WebView错误，'free'叫'abort'。如果你没有自己的本地代码，这是一个Android错误。 – nneonneo

+0

没有本地代码在那里，所以我敢肯定，这也是一个固件的bug =（你有什么想法可以解决什么问题吗？ –

+0

快速更改页面标题会导致大多数droid浏览器崩溃。不是什么在这里发生，但你可能想知道的东西 –

回答

1

我解决了一些低级别的崩溃，包括4.0.4的崩溃，通过禁用格式检测在HEAD中的t他的HTML页面（这是通过在谷歌一个朋友建议）：

<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，我还没有想出一个解决办法这段时间。

来源

2012-11-27 18:15:19 incidentist

+0

非常感谢您的建议！我试着将上面的格式检测代码添加到每个页面，但不幸的是它似乎没有帮助。我有一种感觉，对一些人这真的很有用，虽然... –

5

我正在玩你的crashApp。

使用设备; ■夏普ISW16SH ■LG Optimus Vu L-06D（3〜10页后无法生存）

这些是我经常遇到的错误。IN dlfree 堆内存损坏 致命信号11（SIGSEGV） 堆内存损坏IN dlmalloc

显然，有一个存储器分配或释放双问题。这不是可以解决的问题。 （除非，NDK） 我发现的唯一解决方案是热插拔webview的动态。 总是在新创建的webview中加载下一页将防止发生这种情况。但是，我似乎无法阻止内存掉线。最终Android会在您的应用程序增长到一个吃怪物的内存时触发。

然后我开始玩两个相同的空活动课。 no 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。 我不太确定一些功能（如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？

来源

2012-12-27 02:22:07 Hiro

+0

非常感谢你深入调查!!活动回收是一个可怕的解决方案，因为它降低速度和外观，但鉴于它的作品可能会比替代品更好。我完全同意NDK - 我最终的梦想是休假一周，去异国风情的海滩，然后扣下来编辑我自己的Webview图书馆。 –

+0

没有概率兄弟！ 以及我忘记提及的一件事。 之间的活动交换，我用windowManager创建黑屏。 – Hiro

+0

另外，不错的计划呢！我敢打赌，如果你创建了一个公司，你会愿意从你那里购买。 – Hiro

0

我一直有这个问题（或者至少非常相似）使用http://fgnass.github.io/spin.js/

当我采取了网页的，没有任何问题。也似乎发生在Android 4.0和4.1，但不是4.3

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

来源

2013-10-17 15:57:31 SpeakEasyV

0

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

Erronous代码：

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; 
}

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

来源

2014-12-11 09:36:14 Nilzor

0

个人经验：

我尝试了很多东西，比如不使用RelativeLayout的，不拉丝很多东西web视图的背后，还有更多，因为在这个SIGSEGV 11网页视图问题很多StackOverflow的帖子解释。

在4.1版本的Android版本上发生问题（仅限于？）。

什么工作对我来说：

  • 我停止使用由RoundRectShape的 “接近” 的WebView可绘制。硬件层和圆角之间可能有问题？
  • 我停止在webview（例如进度视图）上放置视图。
  • 我停止做任何事情使布局重新计算而webview在工作。如动态在我的屏幕上添加视图。
    •

尽管如此，有时会由于其他原因导致系统崩溃，大多数情况下，当转到另一个活动并返回到WebView时会发生崩溃。在日志中，我可以看到诸如“webcoreview：nativeDestroy”之类的东西，可能意味着某些东西似乎被某个人随后使用。然后出现SIGSEGV 11。

但至少，发生的频率要低得多。

来源

2015-02-24 16:37:45

2

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

来源

2015-11-26 13:12:59

相关问题

 相关问题