26

我在 Android WebView 中有一个复杂的交互式 HTML5 - 它基本上可以在除 Galaxy S3 之外的所有平台上正常工作。在 Galaxy S3 (Android 4.0.4) 上,每 5 次左右,就在加载完成后,/system/lib/libwebcore.so 尝试访问无效内存和位于 [各种地址的致命信号 11 (SIGSEGV) ] (code=1) 被抛出。

HTML5 是一场小型战斗,敌人出现,用户砍杀他们继续前进。在战斗之间是普通的 html 页面:普通页面 -> HTML5 战斗 -> 普通页面 -> HTML5 战斗 -> 普通页面 -> HTML5 战斗。HTML5 没有做任何特别开箱即用的事情 - 有很多 -webkit-animation 调用......

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

...引用了很多 -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 也会出现挂起。

有没有人遇到过 Galaxy S3 与众不同的问题?没有 Android 2.x 设备有这个问题,甚至运行 4.1.1 的 Galaxy Nexus 似乎也没有任何特别的问题。我以前从来没有想过写信给 Stack Overflow,但这真的让我很烦恼......

搜索“Android WebView sigsegv crash”和“4.0.4 WebView sigsegv crash”会出现几个问题,但是:

由于一些崩溃是在内存释放()期间发生的,我知道在崩溃发生时某些东西正在被释放,我的直觉是有些东西在渲染中被释放,这是不应该的。这令人沮丧,因为 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 复制到从普通 webview 应用程序加载的 2 个 HTML 页面。webview 只是启动并加载:

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

这些页面相互链接,不一定在第一次查看时崩溃,但最终它们在 Android 4.1.1 模拟器和我的 Galaxy Nexus (4.1.1) 上崩溃 100%。请注意,帖子标题是错误的 - 这肯定不仅仅是 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

测试App的启动代码:

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

当且仅当文本页面使用“myblink”标签时,在文本页面和(无 CSS)画布页面之间循环的测试会崩溃。

我谦虚的假设是:

[活动 webkit 动画的解构器] + [同时加载大量下一页] + [时机不好] = [内存损坏]

我这样说是因为,我可能会遗漏一些东西,动画的内容似乎几乎无关紧要。我试过了:

  • 使不透明度始终等于 1
  • 用位置变换替换不透明度
  • 关闭动画循环
  • 将闪烁标签放在图片而不是文本上
  • 玩弄关键帧

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

现在我已经通过将游戏内动画转换为完全基于画布的解决方案来解决游戏中的崩溃问题;^^ 我知道这很激烈。所以我暂时不会进一步调查,但我仍然很乐意将其缩小到特定的 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 页面的任何位置)

4

7 回答 7

6

我在玩你的 crashApp。

使用设备;■ SHARP ISW16SH ■ LG 擎天柱 Vu L-06D(3~10 页后甚至无法生存)

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

显然,存在内存分配或双重释放问题。这不是可以修复的。(除非 NDK)我发现的唯一解决方案是即时热交换 webview。始终在新创建的 web 视图中加载下一页将防止这种情况发生。但是,我似乎无法阻止记忆下降。最终,一旦你的应用成长为一个吃内存的怪物,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。我不太确定某些函数(如 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-27T02:22:07.077 回答
2

对于 RAM 容量较低的三星设备来说,这是一个长期存在的问题。没有解决办法。

于 2015-11-26T13:12:59.153 回答
1

我通过在 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 上,这次我还没有找到解决方法。

于 2012-11-27T18:15:19.907 回答
1

你不是唯一一个有这个问题的人,我一直在谷歌搜索,似乎和其他人一样http://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy- s3-only/77/181155在 S3 的股票导航器上存在 html 5 的错误(在来自不同国家的不同 rom 上尝试过),我尝试的每个 S3 都崩溃了。尝试过镀铬,效果很好。我确定股票导航器上存在错误。

于 2013-02-25T19:07:14.673 回答
0

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

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

除了解决它并找到除了 spin.js 微调器之外的其他东西之外,我们还没有找到解决方案。绝对看起来像一个Android问题。令我恼火的是,它似乎并没有更普遍。

于 2013-10-17T15:57:31.583 回答
0

个人经验:

我尝试了很多东西,比如不使用RelativeLayout,不在webview后面画很多东西,还有更多,正如许多关于这个SIGSEGV 11 Webview问题的StackOverflow帖子所解释的那样。

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

什么对我有用:

  • 我停止使用由 RoundRectShape “接近” WebView 制成的可绘制对象。也许硬件层和圆角之间有问题?
  • 我停止在 webview 上放置视图(例如进度视图)。
  • 我停止做任何会在 webview 工作时重新计算布局的东西。比如在我的屏幕上动态添加一个视图。

尽管如此,有时还是会由于其他原因导致崩溃,主要是在转到另一个活动并返回 WebView 时。在日志中,我可以看到类似“webcoreview: nativeDestroy”之类的内容,这可能意味着某些东西似乎被某人使用然后被某人使用。然后出现 SIGSEGV 11。

但至少,这种情况发生的频率要低得多。

于 2015-02-24T16:37:45.120 回答
0

附和我的情况,因为它有点不同但有相同的症状。我正在通过静态变量*跨设备旋转维护 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;
}

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

于 2014-12-11T09:36:14.007 回答