Сигнал 11 SIGSEGV Crash в Galaxy S3 Android WebView

У меня сложный интерактивный HTML5 в Android WebView - и он отлично работает на всех платформах, кроме Galaxy S3. На Galaxy S3 (Android 4.0.4) один раз каждые 5 или более раз, сразу после завершения загрузки, /system/lib/libwebcore.so пытается получить доступ к недопустимой памяти и фатальному сигналу 11 (SIGSEGV) на [различные адреса ] (код = 1).

HTML5 - это крошечная битва, в которой появляются враги, и пользователь сокращает их. Между битвами находятся обычные html-страницы: нормальная страница → битка HTML5 → нормальная страница → битва HTML5 → обычная страница → битка HTML5. HTML5 не делает ничего особенного из-за-коробки - там много вызовов -webkit-анимации...

.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 эта проблема не возникает, и даже у Galaxy Nexus, работающего на 4.1.1, нет особых проблем. Я никогда не испытывал соблазна писать в Qaru раньше, но это меня очень раздражает...

Поиск в разделе "Синдром Sigsegv для Android WebView" и "4.0.4 сбой WebSig Sigsegv" дает несколько проблем, но:

webview.clearCache()/webView.destroyDrawingCache(), похоже, не имеет эффекта (хотя это зависание явно является проблемой памяти, добавление/удаление System.gc() s в разных местах не было отличным результат) SIGNAL 11 SIGSEGV сбой Android
Нельзя использовать холст, как в Странный рисунок сбоя на холсте на Android 4.0.3. A/libc: фатальный сигнал 11 (SIGSEGV) (Да, я знаю - вызов этой страницы HTML5 немного растягивается)
Нет смысла использовать clearView(), как в выполнить WebView.loadurl() после многопоточного Webview.clearView() приведет к сбою
Нет смысла сохранять-3d как в http://code.google.com/p/android/issues/detail?id=16563
Я просмотрел список изменений для веб-сайта android, ищущий подозрительные исправления после 4.0.4, и подумал, что у меня что-то есть с приведенным ниже, но укоренение S3 и переход к 4.1.1 не устранили проблему: https://github.com/teamgummy/android_external_webkit/commit/61e0d189f2b74650bf72a6a2820f66a8b17c3d06

Так как некоторые из сбоев происходят во время освобождения памяти(), я знаю, что во время сбоя все становится свободным, и мое чувство кишки заключается в том, что некоторые вещи освобождаются срединно, что не должно быть. Это расстраивает, потому что SIGSEGVs должны быть физически невозможны с чистым 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

Обновление 30 ноября:

Мне еще предстоит пройти длинный путь, чтобы сузить это до простого тестового примера, но я получил воспроизведение вышеупомянутого SIGSEGV до 2 HTML-страниц, загруженных из простого приложения webview. Веб-просмотр просто запускается и загружается:

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

Страницы ссылаются друг на друга и не обязательно вылетают с первого взгляда, но в конечном итоге они разбиваются на 100% на эмулятор Android 4.1.1 и мой Galaxy Nexus (4.1.1). Обратите внимание, что заголовок сообщения неправильный - это определенно не только S3.

Интересная вещь,
- Использование webview внутри моего реального приложения, загрузка 1 страницы (crash.html или любой тяжелой страницы HTML5) достаточно много, чтобы вызвать SIGSEGV.
- Используя это обычное приложение для веб-просмотра для тестирования, две страницы нуждаются друг в друге, чтобы сбой - просто загрузка одной страницы неоднократно не умирает.
- Загрузка страниц в веб-браузере Android 4.1.1, даже на 2 страницах недостаточно - она умрет, но требуется много страниц.

С точки зрения местоположения ошибок в авариях существуют разные трассировки стека, некоторые из них относятся к таблицам стилей, другие относятся к деструкторам в HTMLImageElement. Android 2.x, iOS, любой другой браузер прочный.

Javascript изменяет DOM, и этого оказалось достаточно, чтобы вызвать крушение здесь... но почему?
На первый взгляд это ставит меня как проблема сбора мусора - мое приложение собирает мусор раньше, чем обычное приложение для веб-просмотра, потому что оно использует больше памяти в других местах. Однако я не получаю сообщения об ошибках памяти. Я продолжу работу, чтобы сузить это, но любой, кто имеет какие-либо идеи относительно того, как действовать или что может быть проблемой, действительно имеет мою вечную неумирающую привязанность.

Код тестового приложения:

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

Все ресурсы 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");
}

 }

Обновление 3 февраля:

Проблема возникает из-за анимации webkit, которые все еще оживляют, когда страница закрывается. Я сузил один крах до одного тега "myblink":

.myblink{-webkit-animation-name:"anime-blink";-webkit-animation-duration:1.2s;-webkit-animation-timing-function:ease-in-out;-webkit-animation-iteration-count:infinite}
@-webkit-keyframes "anime-blink"{0%{opacity:0}
20%{opacity:1}
60%{opacity:1}
100%{opacity:0}
}

Тест, который циклически перемещался между текстовой страницей и страницей canvas (без CSS), мог бы сработать тогда и только тогда, когда текстовая страница использовала тег myblink.

Моя скромная гипотеза:

[deconstructor для активной webkit-анимации] + [тяжелая следующая страница загружается в одно и то же время] + [неудача с синхронизацией] = [повреждение памяти]

Я говорю это, потому что, и я мог что-то упускать, содержание анимации кажется почти несущественным. Я пробовал:

делает непрозрачность всегда равной 1
замена непрозрачности преобразованием позиции
Отключение цикла анимации
размещение метки мигания на изображении вместо текста
игра с ключевыми кадрами

... но это всегда сбой. Единственное, что могло бы остановить сбой, состояло в том, чтобы отключить цикл анимации, а также сократить продолжительность анимации - то есть сбой остановится, если анимация была закончена до закрытия страницы.

На данный момент я работал над сбоем в игре, превращая внутриигровые анимации в полностью основанное на холсте решение; ^^ Резкое, я знаю. Поэтому я не буду расследовать какое-то время, но все же я бы так хотел сузить это до определенного фрагмента исходного кода вебкита.

Боковое примечание: я хотел бы дать крик:

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

... это либо одна и та же проблема, либо что-то очень похожее.

Обновление 19 ноября:

Исходный сервер был удален в автономном режиме, поэтому в Dropbox был помещен вышеуказанный тестовый код:

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

(Обратите внимание, что URL-адрес в приложении CrashApp должен быть изменен везде, где вы помещаете HTML-страницы)

Ответ 1

Я играл с вашим crashApp.

Использование устройств; ■ SHARP ISW16SH ■ LG optimus Vu L-06D (не может даже выжить после 3-10 страниц)

Это ошибка, которую я часто получал. Фатальный сигнал 11 (SIGSEGV) КОРРУПЦИЯ ПАМЯТИ ПАМЯТИ В dlfree КОРРУПЦИЯ ПАМЯТИ ПАМЯТИ В dlmalloc

Очевидно, есть проблема с распределением памяти или двойным освобождением. И это не то, что можно исправить. (если, NDK) единственным решением, которое я нашел, является "горячая" замена веб-браузера на лету. Всегда загружать следующую страницу во вновь созданный веб-просмотр, чтобы это не происходило. однако, я не могу остановить падение памяти. В конце концов Android ударит, как только ваше приложение превратится в память, в которой есть монстр.

Затем я начинаю играть с двумя идентичными пустым классом активности. нет xml. поэтому,

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


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

　　super.onDestroy();
　　System.gc();　　//clean up what freed in webViewLoadComplete (hopefully)
}

Я также вызвал другой gc в onPageFinished, чтобы убедиться, что другая активность ушла навсегда.

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?

Ответ 2

Я решил несколько низкоуровневых сбоев, включая сбои в 4.0.4, отключив обнаружение формата в HEAD страницы html (это было предложено другом в 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, и на этот раз я не понял обходной путь.

Ответ 3

Вы не единственный с этой проблемой, Я был googling и кажется, что, как этот другой парень http://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy-s3-only/77/181155, есть ошибка с html 5 в штоке запаса на S3 ( пробовал так на разных ромах из разных стран), каждый S3, с которым я пытался, разбился. Пробовал на хром и прекрасно работает. Я уверен, что есть ошибка в навигаторе запаса.

Ответ 4

Это хроническая проблема для более низких емкостных устройств Samsung. Решение отсутствует.

Ответ 5

У меня была эта проблема (или, по крайней мере, очень похожа) с помощью http://fgnass.github.io/spin.js/

Когда я вынимаю это из страницы, проблем нет. Также похоже на Android 4.0 и 4.1, но не 4.3

Нам не удалось найти решение, кроме как обойти его и найти что-то другое, кроме использования spinner.js. Хотя определенно кажется проблемой Android. Меня раздражает то, что оно не кажется более распространенным.

Ответ 6

Взаимодействие с моим делом, поскольку оно немного отличается, но имеет те же симптомы. Я поддерживаю экземпляр 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;
}

*) В качестве побочного примечания я считаю, что это хороший подход к уменьшению следа вращения устройства. Добавленный бонус заключается в том, что веб-просмотр остается прокрученным в позиции, в которой находился пользователь, не требуется перезагрузка страницы. Обратите внимание, что этот подход подразумевает, что вы используете только фрагмент по одному месту в любой заданной активности (singleton).

Ответ 7

Личный опыт:

Я пробовал много вещей, например, не используя RelativeLayout, не занимаясь многими вещами за веб-просмотром, и МНОГО больше, как объяснялось во многих сообщениях StackOverflow об этой проблеме SIGSEGV 11 Webview.

Проблема возникает (только?) на версии 4.1 Android.

Что сработало для меня:

Я прекратил использовать чертежи , сделанные из RoundRectShape, "закрыть" в WebView. Может быть, что-то не так между аппаратным слоем и круглыми углами?
Я остановил размещение просмотров поверх веб-страницы (например, представление прогресса).
Я прекратил делать что-либо, чтобы сделать пересчет макета, пока веб-просмотр работает. Например, динамическое добавление представления на мой экран.

Тем не менее, иногда происходит сбой из-за чего-то другого, в основном при переходе к другому действию и возвращении в WebView. В журналах я вижу что-то вроде "webcoreview: nativeDestroy", вероятно, это означает, что что-то кажется использованным, а затем используется кем-то сразу. Затем появляется SIGSEGV 11.

Но, по крайней мере, это происходит гораздо реже.