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

Joh*_*son 26 html5 android segmentation-fault webview galaxy

我在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;
}
Run Code Online (Sandbox Code Playgroud)

...引用了很多-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;
}
/*…*/
Run Code Online (Sandbox Code Playgroud)

还有一个相当复杂的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"会出现几个问题,但是:

由于在内存free()s期间发生了一些崩溃,我知道事情在崩溃的时候是免费的,我的直觉是有些东西在渲染中被释放,而不应该.令人沮丧的是因为纯HTML,JS和CSS =/SIGSEGV在物理上是不可能的

以下是崩溃报告示例.请注意,碰撞位置不限于以下内容; 崩溃报告似乎没有太大的不同,但位置似乎有一些变化.

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
Run Code Online (Sandbox Code Playgroud)

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

Test 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");
}

 }
Run Code Online (Sandbox Code Playgroud)

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}
}
Run Code Online (Sandbox Code Playgroud)

当且仅当文本页面使用"myblink"标记时,在文本页面和(无CSS)画布页面之间循环的测试才会崩溃.

我谦虚的假设是:

[主动webkit-animation的解构器] + [同时加载下一页重载] + [计时运气不好] = [内存损坏]

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

  • 使不透明度始终等于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)

Hir*_*iro 5

我正在玩你的crashApp.

使用设备; ■夏普ISW16SH■LG optimus Vu L-06D(3~10页后甚至无法存活)

这些是我经常犯的错误.dlmalloc中的致命信号11(SIGSEGV)堆积记忆腐蚀

显然,存在内存分配或双重释放问题.而且这不是可以解决的问题.(除非,NDK)我找到的唯一解决方案是即时热交换webview.始终在新创建的webview中加载下一页将阻止这种情况发生.但是,我似乎无法阻止记忆力下降.最终,一旦你的应用变成了一个吃怪物的记忆,Android就会罢工.

然后我开始玩两个相同的空活动类.没有xml.所以,

onCreate() {
??WebView wv = new WebView(context);
??setContentView( wv );
}


void onDestroy() {
??ViewGroup vg = (ViewGroup)game_wv.getParent();
??vg.removeView(game_wv);
??destroyWebView( game_wv );
??game_wv = null;

??super.onDestroy();
??System.gc();??//clean up what's freed in webViewLoadComplete (hopefully)
}
Run Code Online (Sandbox Code Playgroud)

我还在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
??}
}
Run Code Online (Sandbox Code Playgroud)

这是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();
}
Run Code Online (Sandbox Code Playgroud)

不知怎的,它起作用了......

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


inc*_*ist 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"/>
Run Code Online (Sandbox Code Playgroud)

然而,4.1.1 更新使这些崩溃再次出现在 S3 上,这次我还没有找到解决方法。