Which library is causing this crash? - ios

Question

I've got a symbolicated stack trace that's giving me a headache! Annoyingly, I can't reproduce this on any of our test devices so I only have the crash reports to work from.
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
The reason for the crash is pretty obvious (and isn't my question!) - I'm trying to write a non-jsonable object into json data. The tricky part is working out exactly where this is happening.
All the references to WNLoadingView.m are a complete red herring - that line of WNLoadingView is just #implementation WNLoadingView and the address 0xc9000 is just the starting point of our binary in memory. However, 0x00315fa3 looks like it's in our space but I don't know how to see what's actually there :)
Sigh.
My current theory is that the crash is occurring in a library that I don't have debug information for (i.e. a 3rd party .a linked from a pod).
I guess I have two questions;
How can I use this stack trace to find out which library is causing this?
or
If my theory isn't correct, does anyone know another approach to try or have another theory?

Answer 1

There's a couple of avenues that you might pursue:
Get yourself a fully-symbolicated crash log. I've found this post to be incredibly helpful, specifically the answer by Andreas (which is NOT the accepted answer, unfortunately). If you can get this to work, you may not need anything else.
Use the link map for your binary to determine where the address in question (0x00315fa3) resides. This can potentially be unsolvable if you didn't set up your build to produce a link map ahead of time for the version of your app that's on the app store (or even an older one), but there's a small chance that you can potentially get in the ballpark by rebuilding the app from scratch at the same commit point in your version control system you used to build the app originally (YMM GREATLY V). Regardless of whether you're already set up or need to set up your build to produce one, you'll want one going forward; read the first part of the second post for instructions on setting up your build in Xcode to produce a link map, and where to find it once it's been generated. If you use command-line tools to build your app for submission, you'll need to dig up the relevant switch(es) (you can use your Xcode build changes to determine what it does and use that in your build script/command). The link map is useful because it can tell you about files/methods from ALL of the app's source code, including third-party libraries, even when you don't have the source for them (it's a complete map of your entire app, not just your code); you can still get useful hints about the overall call flow that led directly to the crash.
While the purpose of the second post doesn't directly address your problem (and are frankly overkill for your specific question), many of the ideas about how to read the link map and the tools you can use to automate certain tasks should give you sufficient insight about how to glean the information that's of relevance. Specifically, you'll want to find the file/method invocation whose address range contains the address in question (0x00315fa3), and, if all goes well (meaning you have an accurate map), that information should point you right to the offending library, file, and method.