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 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

看起来像是在我们的空间中，但我不知道如何看到实际存在的东西：）

唉

我目前的理论是，崩溃发生在我没有调试信息的库中（即，从pod链接的第三方

.a

）

我想我有两个问题

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

或

---

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

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

为自己准备一份完全符号化的崩溃日志。我发现这非常有帮助，特别是安德烈亚斯的答案（不幸的是，这不是公认的答案）。如果你能让这个工作，你可能不需要任何其他东西

使用二进制文件的链接映射来确定有问题的地址（

0x00315fa3

）所在的位置。如果您没有将构建设置为提前为应用商店（甚至是旧版本）中的应用程序版本生成链接地图，则此问题可能无法解决，但是，有一个很小的机会，你可以通过在你的版本控制系统中的同一个提交点从头开始重新构建这个应用程序，而这个提交点是你最初用来构建这个应用程序的（YMM V）。不管你是否已经建立或者需要建立你的构建来产生一个，你都会想要一个继续前进；阅读的第一部分，了解如何设置内置Xcode以生成链接映射，以及生成链接映射后在何处查找链接映射的说明。如果您使用命令行工具构建要提交的应用程序，则需要挖掘相关开关（您可以使用您的Xcode构建更改来确定它的功能，并在构建脚本/命令中使用它）。链接映射很有用，因为它可以告诉你所有应用程序源代码中的文件/方法，包括第三方库，即使你没有这些文件/方法的源代码（它是整个应用程序的完整映射，而不仅仅是你的代码）；您仍然可以获得有关直接导致崩溃的整个调用流的有用提示

虽然的目的并不能直接解决您的问题（坦率地说，对于您的特定问题来说，这是过分的），但是关于如何阅读链接图以及可以用于自动化某些任务的工具的许多想法应该能够让您充分了解如何收集相关信息。具体地说，您需要查找其地址范围包含有问题的地址的文件/方法调用（

0x00315fa3

），并且，如果一切顺利（意味着您有一个准确的映射），该信息应该直接指向有问题的库、文件和方法

---

为了更好地理解你的问题，你能回答我的问题吗？让我说，崩溃发生在一些苹果的库中，例如，

NSJSONSerializationLib

在这种情况下你会怎么做？@sage444异常是由苹果库引发的，但因为我的应用程序传入了无效的输入数据。如果我能在我的应用程序中找到导致崩溃的数据在哪里传递，我可以在那里修复它（或者至少在它周围放置一个try/catch并进行恢复）。好的，现在我看到这个日志没有完全符号化，只指向一个文件

WNLoadingView

，而不是精确的行/方法。仅仅开始还不够吗？还要看一下

dispatch\u after

我相信这不是经常使用的，它可以告诉你确切的位置code@sage444我在我的应用程序中搜索了

dispatch\u after

和

dataWithJSONObject

，但如果它发生在第三方预编译库中，我将无法看到它。对dataWithJSONObject的调用看起来都非常正常：）Hi-（1）不起作用，因为我没有库的调试符号，所以无法生成更完整的dSYM。唉。（2） 结合链接中创建链接器映射的说明，我可以在没有调试信息的偏移量处查找二进制文件中的内容。他们都在一个图书馆里，所以我很确定我现在知道了罪魁祸首——是时候和他们一起写一张支持票了……）