ios - 哪个库导致了这个崩溃？

我有一个符号化的堆栈跟踪，这让我很头疼!烦人的是，我无法在我们的任何测试设备上重现这一点，所以我只能使用崩溃报告。

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 dataWithRootObjectptions:error:] + 128 Foundation                     
0x2ba224bf +[NSJSONSerialization dataWithJSONObjectptions: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 看起来像是在我们的空间中，但我不知道如何查看实际存在的内容

叹息。

我目前的理论是崩溃发生在我没有调试信息的库中(即从 pod 链接的第 3 方 .a)。

我想我有两个问题；

如何使用此堆栈跟踪来找出导致此问题的库？

或

如果我的理论不正确，有没有人知道另一种方法来尝试或有另一种理论？

---

Best Answer-推荐答案

您可能会寻求以下几种途径:

1. 为自己获取一个完全符号化的崩溃日志。我找到了this post非常有帮助，特别是 Andreas 的答案(不幸的是，这不是公认的答案)。如果你能做到这一点，你可能不需要其他任何东西。
2. 使用二进制文件的链接映射来确定相关地址 (0x00315fa3) 所在的位置。如果您没有将build设置为提前为应用商店中的应用版本(甚至更旧的版本)生成链接映射，这可能无法解决，但您可以< em>可能通过在您最初用于构建应用程序的版本控制系统中的相同提交点从头开始重建应用程序来进入球场(YMM GREATLY V)。无论您是否已经建立或需要建立您的构建来生产一个，您都会想要一个继续前进；阅读 the second post 的第一部分有关在 Xcode 中设置构建以生成链接映射的说明，以及生成链接映射后的位置。如果您使用命令行工具构建应用程序以进行提交，则需要挖掘相关的开关(您可以使用 Xcode 构建更改来确定它的作用并在构建脚本/命令中使用它) .链接映射很有用，因为它可以告诉您来自所有应用程序源代码的文件/方法，包括第三方库，即使您没有它们的源代码(它是整个应用程序的完整 map ，而不是只是你的代码)；您仍然可以获得有关直接导致崩溃的整体调用流程的有用提示。
3. 而the second post的目的|并不能直接解决您的问题(坦率地说，对于您的特定问题来说，这有点过分了)，许多关于如何阅读链接 map 的想法以及可用于自动化某些任务的工具应该能让您充分了解如何收集信息这是相关的。具体来说，您需要找到地址范围包含相关地址 (0x00315fa3) 的文件/方法调用，如果一切顺利(意味着您有准确的 map )，该信息 < em>应该将你指向有问题的库、文件和方法。

关于ios - 哪个库导致了这个崩溃？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32453028/