2016-11-18 3 views
10

С 8 ноября 2016 года мы увидели внезапное увеличение сбоев из WebThread. Мы не знаем, что вызывает крушение.Сбой: WebThread - EXC_BAD_ACCESS KERN_INVALID_ADDRESS

У нас есть веб-статьи и объявления в приложении. У нас не было выпуска приложений. Не было никаких существенных изменений в сети или рекламе.

Поскольку сбои происходят на экранах без статей, мы думаем, что это происходит в объявлениях.

Кто-нибудь еще видел это? Любые мысли, идеи, что-нибудь?

Стек след:

Crashed: WebThread 
0 WebCore      0x184b7e47c WTF::HashMap<WTF::String, WebCore::ApplicationCacheGroup*, WTF::StringHash, WTF::HashTraits<WTF::String>, WTF::HashTraits<WebCore::ApplicationCacheGroup*> >::remove(WTF::String const&) + 48 
1 WebCore      0x184b7abbc WebCore::ApplicationCacheStorage::cacheGroupDestroyed(WebCore::ApplicationCacheGroup*) + 52 
2 WebCore      0x184b7abbc WebCore::ApplicationCacheStorage::cacheGroupDestroyed(WebCore::ApplicationCacheGroup*) + 52 
3 WebCore      0x184b70628 WebCore::ApplicationCacheGroup::~ApplicationCacheGroup() + 56 
4 WebCore      0x184b70b10 WebCore::ApplicationCacheGroup::~ApplicationCacheGroup() + 12 
5 WebCore      0x184b72334 WebCore::ApplicationCacheGroup::disassociateDocumentLoader(WebCore::DocumentLoader*) + 184 
6 WebCore      0x184a024a0 WebCore::ApplicationCacheHost::~ApplicationCacheHost() + 48 
7 WebCore      0x184a01ad0 WebCore::DocumentLoader::~DocumentLoader() + 168 
8 WebKitLegacy     0x185976ba8 WebDocumentLoaderMac::~WebDocumentLoaderMac() + 84 
9 WebCore      0x184e30a78 WebCore::FrameLoader::detachFromParent() + 324 
10 WebKitLegacy     0x1859e0b08 __29-[WebView(WebPrivate) _close]_block_invoke + 348 
11 WebCore      0x1857842c4 HandleRunSource(void*) + 368 
12 CoreFoundation     0x180ab509c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 
13 CoreFoundation     0x180ab4ab0 __CFRunLoopDoSources0 + 412 
14 CoreFoundation     0x180ab2830 __CFRunLoopRun + 724 
15 CoreFoundation     0x1809dcc50 CFRunLoopRunSpecific + 384 
16 WebCore      0x1849ce108 RunWebThread(void*) + 456 
17 libsystem_pthread.dylib  0x180763b28 _pthread_body + 156 
18 libsystem_pthread.dylib  0x180763a8c _pthread_body + 154 
19 libsystem_pthread.dylib  0x180761028 thread_start + 4 
+0

Вы используете сторонний рекламный блок/SDK? – shallowThought

+0

Вы создаете UIWebView в основной теме? Если нет, попробуйте. – MikeJRamsey56

+0

@shallowThought да, мы используем рекламные сети DFP и FB. Да, мы просматриваем данные объявлений. – kthorat

ответ

0

Две ветви идеи двух изучения:

https://stackoverflow.com/a/32078697/3419541

может быть, что пользователь закрывает веб-просмотра непосредственно перед тем он пытается послать делегата обратный вызов, и он выходит из строя, потому что его не существует.

https://stackoverflow.com/a/31673840/3419541

угадал что-то происходит не так с кэшированием ресурса.

+0

Как я уже сказал в вопросе - мы видим сбои, когда у нас нет веб-просмотров. Сбои не ограничиваются в приложении WebView. Также мы останавливаем загрузку webview и удаляем делегат. – kthorat

0

Проще говоря, авария, которую вы испытываете, связана с утечкой памяти.

Переменная или объект пытается получить доступ к ограниченной памяти, что приведет к этому сбою. Я полагаю, что один из используемых вами рекламных фреймворков/API не обрабатывал обновление iOS 10.1.1 (Build 14B100), которое вышло 31 октября 2016 года. Это может быть причиной вашего краха.

Мне также пришло в голову, что это, похоже, происходит во время какого-то вызова функции закрытия/выхода. Если это так, УДАЛИТЬ, вы освобождаете объекты, переменные и все остальное, которые были назначены памяти, правильно. Если ваш код или программа высвобождает все правильно, то это рекламная среда/API, вызывающая ваши проблемы.

Cheers!

+0

мы видим сбои во всех версиях iOS. Мы действительно проверяли утечки памяти и анализ графика памяти, все кажется хорошим. – kthorat

1

Отвечая на мой вопрос, чтобы добавить более подробную информацию, чем область комментариев.
Не отмечать как ответил, так как у меня нет решения.

К сожалению, мы не смогли решить проблему. К счастью, сбой снизился через 2-3 дня.

Проведя 3 дня, мы были уверены, что это связано с Google Ads. Однако, почему скорость крушения пошла вверх и вниз, все еще остается загадкой для нас.

Некоторые примечания/вывод:

  • ли мы делаем что-то глупое при запросе/обработки объявлений?
    • Возможно, но шансы очень тонкие, как это происходило с существующим стабильным выпуском.
  • Связано ли это с конкретными объявлениями?
    • Коэффициент сбоя снизился, потому что мы больше не обслуживаем это рекламное объявление?
  • Команда GoogleAds пришла на помощь и действовала так, как будто ничего не случилось? потому что ... :)
  • Не новая проблема - Crashlytics показывал первое появление этого типа сбоев за несколько месяцев до этого.
Смежные вопросы