Какая библиотека вызывает этот крах?

Question

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

Application Specific Information: 
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Invalid type in JSON write (NSURLResponseInternal)' 

Last Exception Backtrace: CoreFoundation     
0x2ac7af8f __exceptionPreprocess + 126 libobjc.A.dylib     
0x3932bc8b objc_exception_throw + 38 CoreFoundation     
0x2ac7aed5 -[NSException initWithCoder:] + 0 Foundation      
0x2ba218d1 0x2b8ef000 + 632 Foundation      
0x2ba23463 ___writeJSONObject_block_invoke + 186 CoreFoundation     
0x2ab96f5d __65-[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:]_block_invoke + 92 CoreFoundation     
0x2ab96e7f -[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:] + 174 Foundation  
0x2ba230e3 _writeJSONObject + 414 Foundation      
0x2ba2180f _writeJSONValue + 438 Foundation      
0x2ba21625 -[_NSJSONWriter dataWithRootObject:options:error:] + 128 Foundation      
0x2ba224bf +[NSJSONSerialization dataWithJSONObject:options:error:] + 338 whats-new      
0x00315fa3 0xc9000 (WNLoadingView.m:28) whats-new     
0x00318683 0xc9000 (WNLoadingView.m:28) whats-new     
0x003199fb 0xc9000 (WNLoadingView.m:28) libdispatch.dylib   
0x398bc2cf _dispatch_client_callout + 22 libdispatch.dylib    
0x398c3a3d _dispatch_barrier_sync_f_invoke + 48 whats-new    
0x00319911 0xc9000 (WNLoadingView.m:28) whats-new     
0x003185bb 0xc9000 (WNLoadingView.m:28) whats-new     
0x0031fac3 0xc9000 (WNLoadingView.m:28) whats-new     
0x0031f97f 0xc9000 (WNLoadingView.m:28) whats-new     
0x0031dce3 0xc9000 (WNLoadingView.m:28) libdispatch.dylib   
0x398bc2e3 _dispatch_call_block_and_release + 10 libdispatch.dylib  
0x398c3dff _dispatch_after_timer_callback + 66 libdispatch.dylib  
0x398ce173 _dispatch_source_latch_and_call + 1606 libdispatch.dylib  
0x398bde15 _dispatch_source_invoke + 212 libdispatch.dylib    
0x398c4397 _dispatch_queue_drain + 554 libdispatch.dylib    
0x398beaad _dispatch_queue_invoke + 84 libdispatch.dylib    
0x398c5f9f _dispatch_root_queue_drain + 394 libdispatch.dylib   
0x398c73c3 _dispatch_worker_thread3 + 94 libsystem_pthread.dylib  
0x39a20db5 _pthread_wqthread + 668 libsystem_pthread.dylib   
0x39a20b08 start_wqthread + 8 

Причиной аварии довольно очевидно (и это не мой вопрос!) - я пытаюсь написать, не jsonable объект в данных JSON. Трудная часть точно определяет, где это происходит.

Все ссылки на WNLoadingView.m являются полным отвлекающим маневром - это линия WNLoadingView просто @implementation WNLoadingView и адрес 0xc9000 является лишь отправной точкой нашего двоичном в памяти. Однако 0x00315fa3 выглядит как в нашем пространстве, но я не знаю, как увидеть, что на самом деле есть :)

Вздох.

Моя нынешняя теория заключается в том, что авария происходит в библиотеке, в которой у меня нет отладочной информации (т. Е. Сторонней стороны .a, связанной с контейнером).

У меня есть два вопроса;

Как я могу использовать эту трассировку стека, чтобы узнать, какая библиотека вызывает это?

или

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

Answer 1

Там есть несколько путей, которые вы могли бы преследовать:

1. Получить себе полностью symbolicated журнал сбоев. Я нашел this post невероятно полезным, в частности, ответом Андреаса (который, к сожалению, не является принятым ответом). Если вы можете заставить это работать, вам может не понадобиться ничего другого.
2. Используйте ссылку для вашего двоичного кода, чтобы определить, где находится указанный адрес (0x00315fa3). Это потенциально может быть неразрешимым, если вы не настроили свою сборку, чтобы заранее создать карту ссылок для версии вашего приложения, которая находится в магазине приложений (или даже старше), но есть небольшой шанс, что вы можете потенциально попасть в стадию, перестроив приложение с нуля с той же точки фиксации в вашей системе контроля версий, которую вы использовали для первоначального создания приложения (YMM GREATLY V). Независимо от того, вы уже настроены или вам нужно настроить свою сборку для ее создания, вам нужно идти вперед; прочитайте первую часть the second post для получения инструкций по настройке вашей сборки в Xcode для создания карты ссылок и где ее найти после ее создания. Если вы используете инструменты командной строки для создания своего приложения для отправки, вам нужно будет выкопать соответствующие коммутаторы (вы можете использовать изменения сборки Xcode, чтобы определить, что он делает, и использовать их в скрипте/команде сборки) , Карта ссылок полезна, потому что она может рассказать вам о файлах/методах из ВСЕХ из исходного кода приложения, включая сторонние библиотеки, даже если у вас нет источника для них (это полная карта всего вашего приложения, а не просто ваш код); вы все равно можете получить полезные подсказки об общем потоке вызовов, которые привели непосредственно к сбою.
3. В то время как цель the second post не относится к вашей проблеме напрямую (и, откровенно говоря, излишним из-за вашего конкретного вопроса), многие идеи о том, как читать карту ссылок и инструменты, которые вы можете использовать для автоматизации определенных задач, должны дать вам достаточную информацию о том, как получить информацию, которая имеет значение.В частности, вам нужно найти вызов файла/метода, диапазон адресов которого содержит указанный адрес (0x00315fa3), и, если все пойдет хорошо (что означает, что у вас есть точная карта), эта информация должна указывает вам право на нарушение библиотеки, файла и метода.