Signal 11 SIGSEGV Crash in Galaxy S3 Android WebView

Question

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

Answer 1

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?

Answer 2

It is a chronic problem for lower RAM capacity Samsung devices. There is no solution.

Answer 3

I solved a number of low-level crashes, including crashes on 4.0.4, by disabling format-detection in the HEAD of the html page (this was suggested by a friend at Google):

<meta name="format-detection" content="telephone=no" />
<meta name="format-detection" content="email=no" />
<meta name="format-detection" content="address=no"/>

However, the 4.1.1 update brought these crashes back on the S3, and I haven't figured out a workaround this time.

Answer 4

You're not the only one with this problem, I've been googling and it seems that like this other guy http://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy-s3-only/77/181155 there is a bug with html 5 on the stock navigator on the S3 (tried so on different roms from different countries), every S3 I tried crashed. Tried on chrome and it works beautifully. I'm sure there's a bug on the stock navigator.

Answer 5

I've been having this problem (or at least very similar) using http://fgnass.github.io/spin.js/

When I take that out of the page, there's no problem. Also seems to happen on Android 4.0 and 4.1 but not 4.3

We have not been able to find a solution other than to work around it and find something other than the spin.js spinner to use. Definitely seems like an Android problem though. What irks me is that it doesn't seem to be more widespread.

Answer 6

Chiming in with my case, as it is a bit different but had the same symptoms. I am maintaining the WebView instance across device rotations through a static variable*, but my mistake was calling WebView.restoreState on that instance when it was not necessary.

Erronous code:

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

Fixed code:

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

*) As a side note I think this is a good approach to reducing the footprint of a device rotation. Added bonus is that the webview remains scrolled at the position the user was at, an no page reloading is needed. Note that this approach implies you're only using the fragment one place at a time in any given activity (singleton).

Answer 7

Personal experience:

I tried a lot of things, such as not using RelativeLayout, not drawing many things behind the webview, and MUCH more, as explained on many StackOverflow posts about this SIGSEGV 11 Webview issue.

Problem happens (only?) on 4.1 Android versions.

What worked for me:

• I stopped using drawables made of RoundRectShape "close" to the WebView. Maybe something wrong between the hardware layer and round corners ?
• I stopped putting views OVER the webview (such as a progress view).
• I stopped making anything that would make the layout be re-computed while the webview is at work. Such as adding a view on my screen dynamically.

Still, there is sometimes a crash due to something else, mostly when going to another activity and coming back to the WebView. In logs, I can see something like "webcoreview: nativeDestroy", probably meaning that something seems to be used then used by someone right after. Then the SIGSEGV 11 appears.

But at least, that happens much less frequently.