Crittercism сообщает о сбое на main.m

Краткое описание: у нас произошел сбой SIGABRT на main.m. Единственная информация, которую мы получаем, — это минимальный отчет о сбое от Crittercism, и мы понятия не имеем, как воспроизвести сбой.

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

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

Crashed Thread

libsystem_kernel.dylib 0x387fb350 __pthread_kill + 8 + 8    
libsystem_c.dylib 0x35ada973 abort + 95 + 94    
libc++abi.dylib 0x3307cd4f abort_message + 75 + 74  
libc++abi.dylib 0x33079ff9 _ZL17default_terminatev + 25 + 24    
libobjc.A.dylib 0x326c9a77 _ZL15_objc_terminatev + 147 + 146    
libc++abi.dylib 0x3307a07b _ZL19safe_handler_callerPFvvE + 79 + 78  
libc++abi.dylib 0x3307a114 _ZSt9terminatev + 20 + 19    
libc++abi.dylib 0x3307b599 __cxa_current_exception_type + 1 
libobjc.A.dylib 0x326c99d1 objc_exception_rethrow + 13 + 12 
CoreFoundation 0x38328f21 CFRunLoopRunSpecific + 457 + 456  
CoreFoundation 0x38328d49 CFRunLoopRunInMode + 105 + 104    
UIKit 0x39af947d -[UIApplication _run] + 669 + 668  
UIKit 0x39af62f9 UIApplicationMain + 1121 + 1120    
DM 0x0010e41b main (main.m:14)

Остальные темы (может быть полезно для получения дополнительной информации)

Thread: Unknown Name
libsystem_kernel.dylib 0x387eb648 kevent64 + 24 + 24    
libdispatch.dylib 0x3a048658 _dispatch_mgr_thread$VARIANT$mp + 36 + 35

Thread: Unknown Name
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365

Thread: Unknown Name
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365

Thread: Unknown Name
libsystem_kernel.dylib 0x387eaeb4 mach_msg_trap + 20 + 20
CoreFoundation 0x383b7045 __CFRunLoopServiceMachPort + 129 + 128
CoreFoundation 0x383b5da3 __CFRunLoopRun + 883 + 882
CoreFoundation 0x38328ebd CFRunLoopRunSpecific + 357 + 356
CoreFoundation 0x38328d49 CFRunLoopRunInMode + 105 + 104
WebCore 0x3a3a9a45 _ZL12RunWebThreadPv + 445 + 444  
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308

Thread: Unknown Name
libsystem_kernel.dylib 0x387eaeb4 mach_msg_trap + 20 + 20
CoreFoundation 0x383b7045 __CFRunLoopServiceMachPort + 129 + 128
CoreFoundation 0x383b5da3 __CFRunLoopRun + 883 + 882
CoreFoundation 0x38328ebd CFRunLoopRunSpecific + 357 + 356
CoreFoundation 0x38328d49 CFRunLoopRunInMode + 105 + 104
Foundation 0x327edbcd +[NSURLConnection(Loader) _resourceLoadLoop:] + 309 + 308
Foundation 0x3287167d __NSThread__main__ + 973 + 972
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308

Thread: Unknown Name
libsystem_kernel.dylib 0x387eaf1c semaphore_timedwait_trap + 8 + 8
CoreLocation 0x33ff06e9 _Z22CLClientInvokeCallbackP10__CLClient13CLClientEventP11objc_object + 345 + 344
CoreLocation 0x33ff3d4d ___CLClientCreateConnection_block_invoke_0 + 389 + 388
CoreLocation 0x3402a073 __setEventHandler_block_invoke_0 + 347 + 346
libxpc.dylib 0x33f557e9 _xpc_connection_mach_event + 773 + 772
libdispatch.dylib 0x3a049529 _dispatch_mach_msg_invoke$VARIANT$mp + 125 + 124
libdispatch.dylib 0x3a045e91 _dispatch_queue_drain$VARIANT$mp + 81 + 80
libdispatch.dylib 0x3a0497b7 _dispatch_mach_invoke$VARIANT$mp + 163 + 162
libdispatch.dylib 0x3a045e91 _dispatch_queue_drain$VARIANT$mp + 81 + 80
libdispatch.dylib 0x3a045dc1 _dispatch_queue_invoke$VARIANT$mp + 41 + 40
libdispatch.dylib 0x3a045e91 _dispatch_queue_drain$VARIANT$mp + 81 + 80
libdispatch.dylib 0x3a045dc1 _dispatch_queue_invoke$VARIANT$mp + 41 + 40
libdispatch.dylib 0x3a04691d _dispatch_root_queue_drain + 185 + 184
libdispatch.dylib 0x3a046ac1 _dispatch_worker_thread2 + 85 + 84
libsystem_c.dylib 0x35a75a11 _pthread_wqthread + 361 + 360

Thread: Unknown Name
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365


Thread: Unknown Name
libsystem_kernel.dylib 0x387eaeb4 mach_msg_trap + 20 + 20
CoreFoundation 0x383b7045 __CFRunLoopServiceMachPort + 129 + 128
CoreFoundation 0x383b5da3 __CFRunLoopRun + 883 + 882
CoreFoundation 0x38328ebd CFRunLoopRunSpecific + 357 + 356
CoreFoundation 0x383879bb CFRunLoopRun + 99 + 98
DM 0x0024f947 +[ASIHTTPRequest runRequests] + 151
Foundation 0x3287167d __NSThread__main__ + 973 + 972    
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308

Thread: Unknown Name
libsystem_kernel.dylib 0x387fb594 select$DARWIN_EXTSN + 20 + 20
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308

Thread: Unknown Name
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365

Thread: Unknown Name
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365

Большое спасибо за ваше время - мы очень ценим его.

Спасибо, Юстас


ios crash main crittercism
person Justas    schedule 21.02.2013    source источник
comment
Вы пытались установить собственный обработчик исключений?   -  person trojanfoe    schedule 21.02.2013
comment
@trojanfoe: SDK, используемый Джастасом, уже перехватывает исключения. Пожалуйста, никогда не используйте свои собственные обработчики исключений. Это принесет больше вреда, чем пользы, и это все, но не так просто сделать правильно (даже если это выглядит просто на первый взгляд). Вот сообщение в блоге, в котором показаны некоторые из причин, почему: код/отчет о сбое/   -  person Kerni    schedule 21.02.2013
comment
@ Керни, я не согласен; У меня не было проблем с этим, и я использую свой обработчик исключений для сброса кадров стека в свой собственный файл журнала, который используют мои приложения.   -  person trojanfoe    schedule 21.02.2013

Ответы (2)


arrow_upward
2
arrow_downward

Сбой происходит из-за исключения, см. objc_exception_rethrow в трассировке стека рухнувшего потока, который является основным потоком. К сожалению, Exception Backtrace и Exception Reason недоступны. Без этого вы ничего не сможете сделать. Это покажет вам, где в вашем коде возникло исключение и о чем было фактическое исключение.

Исключения перебрасываются средой выполнения в другой цикл выполнения, и для их перехвата потребуется инфраструктура отчетов о сбоях, поддерживающая это. Crittercism использует PLCrashReporter под капотом, который поддерживает это. Но, возможно, либо у вас установлена ​​старая версия SDK, либо они используют ее старую версию.

person Kerni    schedule 21.02.2013
comment
да, мы используем последнюю версию SDK. И у нас есть надлежащие отчеты для большинства сбоев. Спасибо. - person Justas; 22.02.2013
comment
Содержат ли какие-либо отчеты о сбоях причину исключения или Last Exception Backtrace? Если нет, я бы предложил связаться с Crittercism, если они поддерживают это. И если да, то как его настроить и использовать. Потому что для таких сбоев нет другого способа получить информацию, необходимую для исправления. - person Kerni; 22.02.2013

arrow_upward
1
arrow_downward

@Kerni, спасибо за ваше время!

Мы связались с Crittercism, и они посоветовали нам изучить «хлебные крошки» — это позволило бы нам размещать ряд пользовательских вызовов по всему приложению (где пользователь запускает какое-либо конкретное действие + другие важные системные вызовы), и как только приложение выйдет из строя, Crittercism отключится. храните 99 последних хлебных крошек для нас. Это позволит нам понять, каким был путь пользователя к этому конкретному сбою.

Также мы обнаружили возможность использования метаданных для прямого контакта с пользователями и общения с ними. Это также может позволить нам получить больше информации по конкретному вопросу. И самое главное, это позволит нам более эффективно реагировать на сбои.

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

Спасибо

person Justas    schedule 06.03.2013
comment
И почему бы им не предоставить Last Exception Backtrace, который даст вам подробную информацию без всех этих хлопот? - person Kerni; 06.03.2013
comment
Похоже, это связано с типом проблемы, с которой мы столкнулись в этой конкретной проблеме. Обычно мы получаем Last Exception Backtrace без проблем, но здесь приложение вылетает таким образом, что оно недоступно для нас. Имеет ли это смысл? - person Justas; 08.03.2013
comment
На самом деле нет, в этом нет смысла. Это сбой, вызванный исключением. И когда есть исключение, есть Last Exception Backtrace и строка, показывающая причину исключения. Я не знаю ни одного сценария, в котором это могло бы отсутствовать. - person Kerni; 08.03.2013