studio example android html5 webview segmentation-fault galaxy
https://dl.dropboxusercontent.com/u/56202247/CrashHTMLPagFull.ziphttps://dl.dropboxusercontent.com/u/56202247/CrashApp.ziphttp://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashHTMLPagFull.ziphttp://static0.kl-uswest.ec2.gumi.sg/static/android4crash/CrashApp.zip

example - file upload webview android



Signal 11 SIGSEGV Crash en Galaxy S3 Android WebView (7)

Acorde con mi caso, ya que es un poco diferente pero tuvo los mismos síntomas. Mantengo la instancia de WebView en las rotaciones de dispositivos a través de una variable estática *, pero mi error fue llamar a WebView.restoreState en esa instancia cuando no era necesario.

Código Errónico:

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 enfoque para reducir la huella de la rotación de un dispositivo. La ventaja adicional es que la vista web permanece desplazada en la posición en la que se encontraba el usuario, no se necesita recargar la página. Tenga en cuenta que este enfoque implica que solo está utilizando el fragmento un lugar a la vez en una actividad determinada (singleton).

Tengo un HTML5 complejo e interactivo en una vista web de Android, y funciona bien en prácticamente todas las plataformas, excepto Galaxy S3. En Galaxy S3 (Android 4.0.4), una vez fuera de cada 5 veces, justo después de que se complete la carga, /system/lib/libwebcore.so intenta acceder a una memoria no válida y una señal Fatal 11 (SIGSEGV) en [varias direcciones ] (código = 1) es lanzado.

El HTML5 es una pequeña batalla donde aparecen los enemigos y el usuario los recorta para continuar. Entre batallas se encuentran las páginas html normales: página normal -> batalla de HTML5 -> página normal -> batalla de HTML5 - página normal -> batalla de HTML5. El HTML5 no hace nada particularmente fuera de la caja, hay muchas llamadas de animación de wkkit ...

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

... que hacen referencia a muchos fotogramas clave -kebkit ...

@-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 Javascript desactivado.

¿Alguna vez alguien ha tenido un problema con un Galaxy S3 siendo ... diferente? Ningún dispositivo Android 2.x tiene este problema, e incluso un Galaxy Nexus con 4.1.1 no parece tener ningún problema en particular. Nunca antes he tenido la tentación de escribir en Stack Overflow, pero esto realmente me molesta ...

La búsqueda en "Android WebView sigsegv crash" & "4.0.4 WebView sigsegv crash" da varios problemas, pero:

Dado que algunos de los bloqueos se producen durante la memoria (s), sé que las cosas se están liberando en el momento del fallo y mi intuición es que algunas cosas se liberan a mitad del renderizado que no deberían ser. Es frustrante porque los SIGSEGV deberían ser físicamente imposibles con HTML puro, JS y CSS = /

A continuación se muestra un ejemplo de informe de bloqueo. Tenga en cuenta que la ubicación del accidente no se limita a lo 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 del 30 de noviembre:

Todavía tengo un largo camino por recorrer para reducir esto a un caso de prueba simple, pero he conseguido reproducir el SIGSEGV anterior a 2 páginas HTML cargadas desde una aplicación webview simple. La webview simplemente se inicia y carga:

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

Las páginas se enlazan entre sí y no necesariamente se bloquean en la primera vista, pero eventualmente se bloquean al 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,
- Usar la vista web dentro de mi aplicación real, cargar 1 página (crash.html o cualquier página HTML5 pesada) repetidamente es suficiente para causar el SIGSEGV.
- Al usar esta aplicación de vista web sencilla para las pruebas, las dos páginas necesitan mutuamente para bloquearse, simplemente cargar 1 página repetidamente no morirá.
- Cargar las páginas en el navegador web Android 4.1.1, incluso las 2 páginas no son suficientes, morirá, pero toma 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 bloqueo 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 webview simple porque ha usado más memoria en otros lugares. Sin embargo, no estoy recibiendo mensajes de error de memoria. Seguiré trabajando para reducir esto, pero cualquier persona que tenga alguna idea sobre cómo proceder o cuál podría ser el problema realmente tiene mi eterno afecto eterno.

Código de aplicación de prueba:

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

Aplicación de prueba 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

Código de inicio de la aplicación de prueba:

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 del 3 de febrero:

El problema parece ocurrir debido a las animaciones de webkit que aún se animan cuando se cierra la página. Reduje una caída 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 alternara entre una página de texto y una página de lienzo (sin CSS) se bloquearía si y solo si la página de texto usara la etiqueta "myblink".

Mi humilde hipótesis es:

[deconstructor for webkit-animation activo] + [la siguiente página está cargada al mismo tiempo] + [mala suerte con el tiempo] = [corrupción de memoria]

Digo esto porque, y podría faltar algo, los contenidos de la animación parecen casi irrelevantes. Lo intenté:

  • haciendo opacidad siempre igual 1
  • reemplazando la opacidad con una transformada de posición
  • desactivando la animación
  • Poner la etiqueta de parpadeo en una imagen en lugar de texto
  • jugando con fotogramas clave

... pero siempre se estrellaría. 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 se terminaba antes de cerrar la página.

Por ahora, he resuelto el problema del juego convirtiendo las animaciones del juego en una solución completamente basada en lienzos; ^^ Drastic, lo sé. Así que no investigaré más por un tiempo, pero aún así me encantaría reducir esto a una pieza específica del código fuente de webkit.

Nota al margen: me gustaría dar un saludo a:

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

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

Actualización del 19 de noviembre:

El servidor original fue desconectado, 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 url en la aplicación CrashApp debe cambiarse a donde coloque las páginas HTML)

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

Estaba jugando con tu crashApp.

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

Estos son los errores que a menudo tengo. Señal fatal 11 (SIGSEGV) CORRUPCIÓN DE MEMORIA DE HEAP EN dlfree CORRUPCIÓN DE MEMORIA DE HEAP EN dlmalloc

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

Entonces empiezo a jugar con dos clases de actividad vacía idénticas. no xml. asi que,

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é a otro gc en onPageFinished solo para asegurarme de que la otra actividad se haya 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 seguro de algunas de las funciones (como clearAnimation o clearDisappearingChildren) o cuál es el orden correcto para llamar. Yo solo ... tiré todo allí. decir ah

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

de alguna manera, funcionó ...

¿Piensa que el último método podría estar usando un NDK?

Experiencia personal:

Probé muchas cosas, como no usar RelativeLayout, no dibujar muchas cosas detrás de la vista web, y MUCHO más, como se explica en muchas publicaciones de sobre este tema de la vista web SIGSEGV 11.

Problema pasa (solo?) En 4.1 versiones de Android.

Lo que funcionó para mí:

  • Dejé de usar los elementos dibujables hechos de RoundRectShape "cerca" de WebView. Tal vez algo mal entre la capa de hardware y las esquinas redondas?
  • Dejé de poner vistas SOBRE la vista web (como una vista de progreso).
  • Dejé de hacer cualquier cosa que hiciera que el diseño se volviera a calcular mientras la vista web está funcionando. Como agregar una vista en mi pantalla dinámicamente.

Sin embargo, a veces se produce un bloqueo debido a otra cosa, sobre todo al pasar a otra actividad y volver a la vista web. En los registros, puedo ver algo como "webcoreview: nativeDestroy", probablemente significa que algo parece ser usado y luego usado por alguien inmediatamente después. Entonces aparece el SIGSEGV 11.

Pero al menos, eso sucede con mucha menos frecuencia.

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

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

No hemos podido encontrar una solución que no sea trabajar con ella y encontrar otra cosa que no sea el spin.js spinner para usar. Sin embargo, definitivamente parece un problema de Android. Lo que me molesta es que no parece estar más extendido.

Resolví varios bloqueos de bajo nivel, incluidos los bloqueos en 4.0.4, deshabilitando la detección de formato en el HEAD de la página html (esto fue sugerido por un amigo de 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 trajo estos bloqueos al S3, y esta vez no he encontrado una solución alternativa.