Ниже приведен отчет о сбоях, полученный мной от Crittercism, где имя аварии указано как SIGSEGV, а причиной является SEGV_MAPERR.Как диагностировать отчет об аварии iOS (SIGSEGV) от Crittercism
0 libobjc.A.dylib 0x0000000196363bd0 objc_msgSend + 12
1 UIKit 0x00000001893df9bc -[UIScrollView(UIScrollViewInternal) _notifyDidScroll] + 68
2 UIKit 0x000000018911cb9c -[UIScrollView setContentOffset:] + 496
3 UIKit 0x00000001891d2880 -[UITableView setContentOffset:] + 296
4 UIKit 0x00000001893e0634 -[UIScrollView(UIScrollViewInternal) _adjustContentOffsetIfNecessary] + 860
5 UIKit 0x00000001891d8b64 -[UIScrollView(UIScrollViewInternal) _stopScrollingNotify:pin:tramplingDragFlags:] + 396
6 UIKit 0x00000001891d898c -[UIScrollView removeFromSuperview] + 40
7 UIKit 0x00000001890fda08 -[UIView dealloc] + 436
8 libobjc.A.dylib 0x0000000196369724 (anonymous namespace)::AutoreleasePoolPage::pop() + 560
9 CoreFoundation 0x0000000184564d14 _CFAutoreleasePoolPop + 24
10 CoreFoundation 0x00000001846395f4 __CFRunLoopRun + 1496
11 CoreFoundation 0x0000000184564f74 CFRunLoopRunSpecific + 392
12 GraphicsServices 0x000000018dfbf6fc GSEventRunModal + 164
13 UIKit 0x0000000189166d94 UIApplicationMain + 1484
14 MyApplication 0x000000010004bd80 main (main.m:7)
15 libdyld.dylib 0x00000001969faa08 start + 0
Хотя выход уже symbolicated, это все еще довольно трудно понять, что и где на самом деле проблема.
Первоначально, я думал, что я продолжал называть делегата или источник данных таблицы TableView даже после того, как они ушли, поэтому я добавил слежение за всеми контроллерами представлений всякий раз, когда был использован делегат tableview. Однако это не разрешило крах.
- (void) dealloc {
if (self.tableView) {
self.tableView.delegate = nil;
self.tableView.dataSource = nil;
}
}
Я также попытался поворота на «Enable Zombie Objects» вариант в XCode, но в данный момент я не в состоянии воспроизвести это локально.
Эта авария происходит в основном на iPhone 5s/6 (около 45% каждый) с версиями iOS от 8.0 до последних 8.4.1. Приложение использует ARC.
Заранее спасибо.
Вы пытались включить точку останова исключения, чтобы увидеть, где именно происходит авария? (Извините, если это слишком очевидно). Кроме этого, я заметил, что UIScrollView удаляется из супервизора, а затем _notifyDidScroll вызывается непосредственно перед сбоем. Является ли объект UIScrollView еще действительным в контексте? Какое действие предшествует сбою? Является ли это воспроизводимым? –
Поскольку авария происходит случайно на стороне клиента (и я точно не знал, где именно), в этом случае немного сложно использовать контрольную точку исключения. Я изучаю UIScrollView и пока не нашел ничего полезного. – Azu
Если авария случайная, и добавление контрольной точки исключения не указывает источник, возможно, есть утечка памяти. Вы пытались запустить приложение через инструменты, чтобы посмотреть на производительность? –