Señal 11 SIGSEGV Accidente en Galaxy S3 Android WebView

Tengo un HTML5 complejo e interactivo en Android WebView, y funciona bien en básicamente todas las plataformas, excepto Galaxy S3. En Galaxy S3 (Android 4.0.4), una vez cada 5 veces más o menos, justo después de que se completa la carga, /system/lib/libwebcore.so intenta acceder a la memoria no válida y a una señal fatal 11 (SIGSEGV) en [varias direcciones ] (código = 1) se lanza.Señal 11 SIGSEGV Accidente en Galaxy S3 Android WebView

El HTML5 es una pequeña batalla en la que aparecen los enemigos y el usuario los recorta para continuar. Entre batallas están las páginas html normales: página normal -> batalla HTML5 -> página normal -> batalla HTML5 -> página normal -> batalla HTML5. El HTML 5 no hace nada en particular fuera de la caja - hay un montón de webkit-animación de llamadas ...

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

... que la referencia mucha webkit-fotogramas clave ...

@-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; 
} 
/*…*/

Y un árbol div bastante complejo, pero nada particularmente experimental. Hay un cierto nivel de Javascript, pero los bloqueos parecen ocurrir incluso con todo el Javascript desactivado.

¿Alguien ha tenido un problema con un Galaxy S3 siendo ... diferente? Ningún dispositivo con Android 2.x tiene este problema, e incluso un Galaxy Nexus con 4.1.1 no parece tener ningún problema en particular. Nunca he estado tentado a escribir en desbordamiento de pila antes, pero esto es realmente me irritante ...

Buscando en "accidente WebView Android SIGSEGV" & "accidente 4.0.4 WebView SIGSEGV" da varias cuestiones, pero:

webview.clearCache()/webView.destroyDrawingCache() no parecen tener un efecto (aunque este truco es claramente un problema de memoria, añadir/eliminar System.gc() s en varios lugares no tenían gran resultado) SIGNAL 11 SIGSEGV crash Android
No hay uso del lienzo como en Strange crash drawing on canvas on Android 4.0.3. A/libc: Fatal signal 11 (SIGSEGV) (Sí, lo sé - pidiendo esta página HTML 5 es un poco exagerado)
No hay uso de clearView() como en execute WebView.loadurl() after Webview.clearView() multitimes will cause crash
No hay uso de preservar-3d como en http://code.google.com/p/android/issues/detail?id=16563
Miré la lista de cambios para Android webkit buscando soluciones sospechosas después de la 4.0.4, y pensé que tenía algo con lo siguiente, pero rootear el S3 y llevarlo a 4.1.1 no solucionó el problema: https://github.com/teamgummy/android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f66a8b17c3d06

Dado que algunos de los accidentes están ocurriendo durante la memoria libre() s, sé que las cosas se están free'd alrededor del momento del accidente y mi primera impresión es que algunas cosas están siendo liberados a mediados render eso no debería ser Es frustrante porque los SIGSEGV deben ser físicamente imposibles con HTML puro, JS, & CSS =/

A continuación se muestra un informe de fallas de muestra. Tenga en cuenta que la ubicación del bloqueo no está limitada a la siguiente; los informes de fallos no parecen ser muy diferentes, pero parece haber alguna variación en la ubicación.

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

Actualización Nov trigésima:

todavía tengo un largo camino por recorrer para reducir esto a un caso de prueba simple, pero he conseguido la reproducción de la SIGSEGV arriba abajo a 2 páginas HTML cargado desde una aplicación webview simple. La vista web simplemente se pone en marcha y cargas:

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

Las páginas que enlazan entre sí, y no necesariamente accidente en la primera vista, pero con el tiempo se estrellan 100% en el emulador de Android 4.1.1 y mi Galaxy Nexus (4.1.1). Tenga en cuenta que el título de la publicación es incorrecto; esto definitivamente no es solo S3.

Lo interesante es
- Usando la vista web dentro de mi aplicación real, cargar 1 página (crash.html o cualquier página pesada de HTML5) es suficiente para provocar el SIGSEGV.
- Al usar esta aplicación de vista web simple para probar, las dos páginas se necesitan una a la otra, simplemente cargando 1 página repetidamente no morirá.
- Cargando las páginas en el navegador web Android 4.1.1, incluso las 2 páginas no son suficientes: morirá pero tardará muchas páginas.

En cuanto a la ubicación del error, hay diferentes seguimientos de pila en los bloqueos, algunos relacionados con las hojas de estilo, otros relacionados con los destructores en HTMLImageElement. Android 2.x, iOS, cualquier otro navegador es sólido como una roca.

Javascript cambia el DOM, y eso parece ser suficiente para causar el colapso aquí ... pero ¿por qué?
A primera vista, esto me parece un problema de recolección de basura: mi aplicación recolectaría basura antes que la aplicación de vista web simple porque ha usado más memoria en otros lugares. Sin embargo, no recibo mensajes de error de memoria. Continuaré trabajando para reducir esto, pero cualquier persona con alguna idea sobre cómo proceder o cuál podría ser el problema realmente tiene mi eterno afecto eterno.

Prueba Código Aplicación:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip

prueba de una aplicación APK:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.apk

Todos los recursos HTML:

http://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.zip

Prueba A código de inicio de págs:

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

}

actualización Feb 3º:

El problema parece ocurrir debido a webkit-animaciones que todavía están animando al cerrar la página. Entrecerré abajo un accidente a una sola etiqueta "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} 
}

Una prueba que cicla entre una página de texto y una página de lona (sin-CSS) sería se estrellaría si y sólo si la página de texto usa la " etiqueta myblink ".

Mi humilde hipótesis es:

[Deconstructor para webkit-animación activa] + [pesada siguiente página se carga al mismo tiempo] + [mala suerte con el tiempo] = [corrupción de memoria]

digo esto porque, y podría extrañar algo, el contenido de la animación parece casi irrelevante. Probé:

hacer opacidad siempre igual a 1
sustitución de opacidad con una posición transformada
apagar animación en bucle
poner la etiqueta de abrir y cerrar en una imagen en lugar de texto
jugar con fotogramas clave

... pero siempre se bloqueará. Lo único que detendría el bloqueo era desactivar el bucle de animación y también acortar la duración de la animación; es decir, el bloqueo se detendría si la animación finalizaba antes de que se cerrara la página.

Por ahora he trabajado en la caída del juego al convertir animaciones en el juego a una solución completamente basada en lienzo; ^^ Drastic, lo sé. Así que no voy a investigar más por un tiempo, pero aún así me encantaría reducir esto a una pieza específica de código fuente webkit.

Nota al margen: Me gustaría dar un shoutout a:

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

... que es o bien el mismo problema o algo muy similar.

Actualización Nov 19na:

El servidor original fue tomada fuera de línea, por lo que ha colocado el código de prueba anterior en Dropbox:

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

(Tenga en cuenta que la URL en la solicitud CrashApp tiene que ser cambiado a donde pones las páginas HTML)

Fuente

2012-10-11 John Abrehamson

Error de WebView, 'free' llamado' abort'. Si no tiene ningún código nativo, este es un error de Android. – nneonneo

No hay ningún código nativo, así que estoy bastante seguro de que también es una falla de firmware = (¿Tiene alguna idea sobre lo que podría funcionar como una solución? –

Cambiar el título de la página rápidamente bloqueará la mayoría de los navegadores de droides. Creo que esto es no es lo que está sucediendo aquí, sino algo que quizás quieras saber –

He resuelto un número de bloqueos de bajo nivel, incluidos bloqueos en 4.0.4, desactivando la detección de formato en HEAD of t que la página HTML (esto fue sugerido por un amigo en Google):

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

Sin embargo, la actualización 4.1.1 trajeron estos choques de vuelta en el S3, y no he encontrado una solución en esta ocasión.

Fuente

2012-11-27 18:15:19 incidentist

¡Muchas gracias por el consejo! Traté de agregar el código de detección de formato anterior a cada página, pero desafortunadamente no pareció ayudar. Tengo la sensación de que para algunas personas esto realmente será útil ... –

Estaba jugando con tu crashApp.

Uso de dispositivos; ■ SHARP ISW16SH ■ LG optimus Vu L-06D (no puede sobrevivir incluso después de 3 ~ 10 páginas)

Estos son los errores que a menudo tengo. señal 11 (SIGSEGV) memoria de la pila CORRUPCIÓN EN dlfree daños en la memoria montón en dlmalloc

Obviamente, hay una asignación de memoria o un problema de doble liberación. Y no es algo que pueda arreglarse. (a menos que, NDK) la única solución que encontré es cambiar en caliente la vista web sobre la marcha. Cargar siempre la página siguiente en la vista web recién creada evitará que esto suceda. sin embargo, no puedo evitar que la memoria caiga. Eventualmente, Android llegará una vez que tu aplicación se convierta en un monstruo que come memoria.

Luego empiezo a jugar con dos clases de actividad vacías idénticas. no xml. así,

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

También llamé otra gc en el onPageFinished sólo para asegurarse de la otra actividad se ha ido para siempre.

public final class WvClient extends WebViewClient { 
　　public void onPageFinished(WebView wv, String url) { 
　　　　webViewLoadComplete(game_wv); 
　　　　System.gc();　　//clean up the other activity 
　　} 
}

aquí está el destroyWebView y webViewLoadComplete. No estoy tan seguro de algunas de las funciones (como clearAnimation o clearDisappearingChildren) o cuál es el orden correcto para llamar. Yo solo ... arrojé todo allí. ja

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

alguna manera, funcionó ...

creo que el último método podría ser el uso de un NDK?

Fuente

2012-12-27 02:22:07 Hiro

¡Muchas gracias por investigar con tanta profundidad! El reciclaje de actividades es una solución aterradora, porque degrada la velocidad y la apariencia, pero dado que funciona, puede ser mejor que las alternativas. Estoy totalmente de acuerdo con NDK: mi mayor sueño es tomarme una semana libre del trabajo, ir a una playa exótica, y simplemente abrocharme y compilar mi propia biblioteca Webview. –

¡Ningún problema! y, una cosa que olvidé mencionar. entre el intercambio de actividad, he utilizado windowManager para crear la pantalla en negro. – Hiro

¡También, buen plan también! Apuesto a que mucha compañía estará dispuesta a comprarlo si usted creó uno. – Hiro

No eres el único con este problema, He estado buscando en Google y parece que como este otro chico http://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy-s3-only/77/181155 hay un error con html 5 en el navegador de stock en el S3 (probado así en diferentes roms de diferentes países), cada S3 que probé se bloqueó. Intentó en Chrome y funciona muy bien. Estoy seguro de que hay un error en el navegador de stock.

Fuente

2013-02-25 19:07:14 Dante

He estado teniendo este problema (o al menos muy similar) usando http://fgnass.github.io/spin.js/

Cuando tomo eso fuera de la página, no hay problema. También parece suceder en Android 4.0 y 4.1 pero no en 4.3

No hemos podido encontrar otra solución que trabajar en su alrededor y encontrar algo más que el spinner de spin.js para usar. Definitivamente parece un problema con Android. Lo que me molesta es que no parece estar más extendido.

Fuente

2013-10-17 15:57:31 SpeakEasyV

Acompañando mi caso, ya que es un poco diferente pero tenía los mismos síntomas. Estoy manteniendo la instancia de WebView en rotaciones de dispositivos a través de una variable estática *, pero mi error fue llamar al WebView.restoreState en esa instancia cuando no era necesario.

código 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; 
}

Código fijo:

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

*) Como nota al margen, creo que este es un buen método para reducir la huella de una rotación dispositivo. La ventaja añadida es que la vista web permanece desplazada en la posición en la que estaba el usuario, y no es necesario volver a cargar la página.Tenga en cuenta que este enfoque implica que solo está utilizando el fragmento un lugar a la vez en cualquier actividad (singleton).

Fuente

2014-12-11 09:36:14 Nilzor

La experiencia personal:

he intentado un montón de cosas, tales como no usar RelativeLayout, no sacar muchas cosas detrás de la vista web, y mucho más, como se explica en muchos puestos StackOverflow sobre este tema Webview SIGSEGV 11.

El problema ocurre (¿solo?) En las versiones de Android 4.1.

lo que funcionó para mí:

he dejado de utilizar dibujables hechos de RoundRectShape "cerca" de la vista Web. Tal vez algo malo entre la capa de hardware y las esquinas redondas?
Detuve poniendo vistas OVER the webview (como una vista de progreso).
Deje de hacer cualquier cosa que haga que el diseño se vuelva a calcular mientras funciona la vista web. Como agregar una vista en mi pantalla dinámicamente.

Aún así, algunas veces se produce un bloqueo debido a otra cosa, sobre todo cuando se va a otra actividad y se vuelve al WebView. En los registros, puedo ver algo como "webcoreview: nativeDestroy", lo que probablemente significa que algo parece ser utilizado por alguien más. Entonces aparece el SIGSEGV 11.

Pero al menos, eso sucede con mucha menos frecuencia.

Fuente

2015-02-24 16:37:45

Es un problema crónico para los dispositivos Samsung de menor capacidad de RAM. No hay solución.

Fuente

2015-11-26 13:12:59

Señal 11 SIGSEGV Accidente en Galaxy S3 Android WebView

Respuesta

Cuestiones relacionadas