GalaxyS3でシグナル11SIGSEGVがクラッシュAndroid WebView

Question

Android WebView-に複雑でインタラクティブなHTML5があり、Galaxy S3を除く基本的にすべてのプラットフォームで正常に動作します。GalaxyS3（Android 4.0.4）では、5回に1回またはそのため、ロードが完了した直後に、/ system/lib/libwebcore.soは無効なメモリにアクセスしようとし、[さまざまなアドレス]（code = 1）で致命的なシグナル11（SIGSEGV）がスローされます。

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を実行しているGalaxyNexusでも特に問題はないようです。これまでにStackOverflowに書き込みたくありませんでした。、しかしこれは本当に私を悩ませています...

「AndroidWebViewsigsegvcrash」と「4.0.4WebViewsigsegvcrash」で検索すると、いくつかの問題が発生しますが、次のようになります。

webview.clearCache（）/ webView.destroyDrawingCache（）は効果がないようです（このハングは明らかにメモリの問題ですが、さまざまな場所でSystem.gc（）を追加/削除しても大きな結果はありませんでした） SIGNAL 11 SIGSEGVクラッシュAndroid
のようにキャンバスを使用することはありませんAndroid4.0.3。A/ libc：致命的なシグナル11（SIGSEGV）（はい、わかっています-このページをHTML5と呼ぶのは少し難しいです）
Webview.clearView（）が何度もクラッシュを引き起こした後に execute WebView.loadurl（）のようにclearView（）を使用することはありません
http://code.google.com/p/Android/issues/detail?id=16563 のようにpreserve-3dを使用することはありません
Android webkit for 4.0.4以降の疑わしい修正を探しているので、以下の問題があると思いましたが、S3をroot化して4.1.1に移行しても修正されませんでした。問題： https://github.com/teamgummy/Android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f66a8b17c3d06

クラッシュのいくつかはメモリfree（）の間に発生しているので、クラッシュの前後に物事が解放されていることを知っています。私の直感では、レンダリングの途中で解放されるべきではないものもあります。 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をプレーンなWebビューアプリからロードされた2つのHTMLページに複製することができました。 Webビューが起動して読み込まれるだけです。

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

ページは相互にリンクしており、最初のビューで必ずしもクラッシュするわけではありませんが、最終的にはAndroid 4.1.1エミュレーターと私のGalaxyNexus（4.1.1）で100％クラッシュします。投稿のタイトルが間違っていることに注意してください-これは間違いなくS3だけではありません。

面白いのは、
-実際のアプリ内でWebビューを使用して、1ページ（crash.htmlまたは重いHTML5ページ）を繰り返しロードするだけで、SIGSEGVが発生します。
-このプレーンなWebViewアプリをテストに使用すると、2つのページが互いにクラッシュする必要があります。1ページを繰り返しロードするだけでは死にません。
-Android 4.1.1 Webブラウザにページをロードします。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

アプリのスタートアップコードをテストします。

 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アニメーションが原因で発生しているようです。 1つのクラッシュを1つの「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に等しくする
不透明度を位置変換に置き換える
アニメーションのループをオフにする
テキストの代わりに画像に点滅タグを付ける
キーフレームで遊んで

…しかし、それは常にクラッシュします。クラッシュを停止する唯一のことは、アニメーションのループをオフにし、アニメーションの期間を短縮することでした。つまり、ページが閉じる前にアニメーションが終了すると、クラッシュが停止します。

今のところ、ゲーム内のアニメーションを完全にキャンバスベースのソリューションに変換することで、ゲーム内のクラッシュを回避しました; ^^抜本的です。そのため、しばらくはこれ以上調査しませんが、それでも、これを特定の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ページを配置する場所に変更する必要があることに注意してください）

Hiro · Answer

私はあなたのcrashAppで遊んでいました。

デバイスの使用; ■SHARPISW16SH■LG optimus Vu L-06D（3〜10ページを過ぎても生き残れない）

これらは私がよく受けるエラーです。致命的なシグナル11（SIGSEGV）dlfreeのHEAP MEMORY CORRUPTIONdlmallocのHEAPMEMORY CORRUPTION

明らかに、メモリ割り当てまたは二重解放の問題があります。そして、それは修正できるものではありません。（NDKを除いて）私が見つけた唯一の解決策は、その場でWebビューをホットスワップすることです。新しく作成されたWebビューに常に次のページをロードすると、これが発生しなくなります。しかし、私は記憶が落ちるのを止めることができないようです。最終的にAndroidは、アプリが記憶を食べるモンスターに成長すると攻撃します。

次に、2つの同じ空のアクティビティクラスで遊び始めます。 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を使用することだと思いますか？

Osman Yalın · Answer

RAM容量のSamsungデバイスの場合は慢性的な問題です。解決策はありません。

Dante · Answer

この問題を抱えているのはあなただけではありません。私はグーグルをしていて、この他の人のようです http://developer.samsung.com/forum/thread/why-would-webview-hang- with-galaxy-s3-only/77/181155 S3のストックナビゲーターにhtml5のバグがあり（さまざまな国のさまざまなROMで試してみました）、試したすべてのS3がクラッシュしました。 chromeで試してみましたが、うまく機能します。ストックナビゲーターにバグがあると思います。

incidentist · Answer

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に戻ったため、今回は回避策を見つけていません。

Benjamin Piette · Answer

個人的体験：

このSIGSEGV11 Webviewの問題に関する多くのStackOverflowの投稿で説明されているように、RelativeLayoutを使用しない、Webビューの背後に多くのものを描画しないなど、多くのことを試しました。

4.1 Androidバージョンで問題が発生します（のみ？）。

私のために働いたこと：

ドローアブルの使用をやめましたRoundRectShape製 WebViewに「近い」。たぶん、ハードウェア層と丸い角の間で何か問題がありますか？
停止しましたビューをWebビューの上に置く（進行状況ビューなど）。
Webビューが機能している間、レイアウトを再計算するものを作成するのをやめました。画面に動的にビューを追加するなど。

それでも、主に別のアクティビティに移動してWebViewに戻ったときに、他の何かが原因でクラッシュすることがあります。ログには、「webcoreview：nativeDestroy」のようなものがあります。これはおそらく、何かが使用された後、すぐに誰かによって使用されたように見えることを意味します。次に、SIGSEGV11が表示されます。

しかし、少なくとも、それははるかに少ない頻度で発生します。

Nilzor · Answer

少し違いますが同じ症状だったので、私の場合はチャイムを鳴らします。静的変数*を介してデバイスのローテーション全体で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; }

*）補足として、これはデバイスの回転のフットプリントを削減するための良いアプローチだと思います。追加されたボーナスは、Webビューがユーザーがいた位置でスクロールされたままであり、ページを再ロードする必要がないことです。このアプローチは、特定のアクティビティ（シングルトン）で一度に1つの場所でのみフラグメントを使用することを意味することに注意してください。

SpeakEasyV · Answer

私は http://fgnass.github.io/spin.js/ を使用してこの問題を抱えています（または少なくとも非常に似ています）

それをページから取り出しても問題ありません。 Android 4.0および4.1でも発生するようですが、4.3では発生しないようです

それを回避し、spin.jsスピナー以外で使用するものを見つける以外に解決策を見つけることができませんでした。確かにAndroidの問題のようですが、私を苛立たせているのは、それがもっと広まっていないように見えることです。