2

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?

deanWombourne
  • 38,189
  • 13
  • 98
  • 110
  • To better understand your problem can you answer my question ? Let I say that crash happens inside some apple's library e.g. `NSJSONSerializationLib` what you will do in this case ? – sage444 Sep 08 '15 at 08:50
  • @sage444 The exception is being thrown by an Apple library but because of invalid input data passed in by my app. If I can find out where in my app I'm passing in the data that's causing the crash I can fix it there (or at the very least put a try/catch around it and recover). – deanWombourne Sep 08 '15 at 08:53
  • ok, now I see that this log not fully symbolicated and point only to one file `WNLoadingView` but not to exact line/method. Isn't enough to start ? – sage444 Sep 08 '15 at 08:59
  • also look at `dispatch_after` I believe this isn't so frequently used and can point you to exact place or two in code – sage444 Sep 08 '15 at 09:03
  • @sage444 I've searched for both `dispatch_after` and `dataWithJSONObject` in my app, but if it's happening in a 3rd party pre-compiled library I won't be able to see it. The calls to dataWithJSONObject all look perfectly sane :) – deanWombourne Sep 08 '15 at 09:05
  • Ok, you are right, lets try from other side) at first got fully symbolicated log, because if `whats-new` is name of your app this means that last call was from it not from another lib. – sage444 Sep 08 '15 at 09:10
  • you are right again about how it's represented in log but you should agree that in fully symbolicated log we should see at least point from where your app calls third-party lib's methods or I'm still missing something ? – sage444 Sep 08 '15 at 09:43
  • Because its's called as an async method from gcd, I'm assuming that _every_ line in this stack trace is internal to the 3rd party library :( Other stack traces for different crashes have symbolicated as you would expect, it's just this one that's totally opaque. – deanWombourne Sep 08 '15 at 10:27
  • you almost convinced me that this problem has no solution:) but gcd just switches execution to another thread, what is going on in parallel threads ? – sage444 Sep 08 '15 at 10:52
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/89090/discussion-between-deanwombourne-and-sage444). – deanWombourne Sep 08 '15 at 16:36
  • Can you update with full crash log? – Rukshan Sep 17 '15 at 06:56
  • @sleepwalkerfx Do you mean fully symbolicated? If I could do that I'd just read the answer directly from the stack trace and this question wouldn't exist ;) The library in question has the debug symbols stripped before I get it so this is all I have :( Or do you mean all the other threads / memory map? – deanWombourne Sep 17 '15 at 12:46
  • @deanWombourne yes. the whole log. It might help to identify the issue. – Rukshan Sep 17 '15 at 12:56
  • @sleepwalkerfx Hi, the answer by [fullofsquirrels](http://stackoverflow.com/a/32597609/13000) has answered the question - thanks for helping though :) – deanWombourne Sep 17 '15 at 13:19

1 Answers1

1

There's a couple of avenues that you might pursue:

  1. 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.
  2. 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.
  3. 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.
Community
  • 1
  • 1
fullofsquirrels
  • 1,828
  • 11
  • 16
  • Hi - (1) won't work because I don't have the debug symbols for the library so I can't make a dSYM that's more complete. sigh. (2) combined with the instructions in the link to make a linker map let me lookup what's in my binary at the offsets I don't have debug info for. They're all within a single library so I'm pretty sure I now know the culprit - time to write a support ticket with them . . . . :) – deanWombourne Sep 17 '15 at 13:18