CODEWITHSUNDEEP
objective-c
Segev
Segev

Reputation: 19303

debugging in general and [__NSCFBoolean objectForKey:]

2013-01-08 16:02:55.341 TodayApp[95470:14003] -[__NSCFBoolean objectForKey:]: unrecognized selector sent to instance 0x9b4964
2013-01-08 16:02:55.342 TodayApp[95470:14003] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean objectForKey:]: unrecognized selector sent to instance 0x9b4964'
*** First throw call stack:
(0x883012 0x20a2e7e 0x90e4bd 0x872bbc 0x87294e 0x7afc 0x234353f 0x2355014 0x23457d5 0x829af5 0x828f44 0x828e1b 0x2dcf7e3 0x2dcf668 0xfea65c 0x2679 0x2585)
libc++abi.dylib: terminate called throwing an exception

My app got almost 30 classes. I'm getting the above error when I enter a specific vc but only 1 time out of ten so there is no way for me to reproduce it. How can I debug this in an efficient way? Usually I "debug" using NSLog and step by step but I'm sure you can enlighten me with more efficient ways.

Update: I've added exceptions as suggested in the answers in this is the problematic line: NSString *card = [NSString stringWithFormat:@"%@-%@",[[UserAccount sharedInstance] cardNumber],[tokenData objectForKey:@"CardPhoneToken"]]; I'm still trying to figure out what is wrong with it.

Upvotes: 1

Views: 884

Answers (3)

Roland Keesom
Roland Keesom

Reputation: 8288

Set up exception breakpoints for all exceptions on throw and on catch.

This can be done in the bottom right of the BreakPoint Navigator on the '+' sign. Add Exception Breakpoint... And select for Break: On Throw and create another one for On Catch

This should create a breakpoint that will help you identify where any exceptions are being generated.

A more cumbersome way is to create a dSYM-file and run an atos command.

This is done by archiving your project. Then in the Organizer right click the archive and show in finder. Then right click and show package content. Copy the TestApp.app.dSYM to a convenient location and navigate there in terminal.

Then type:

cd Contents/Resources/DWARF/

Then you can run the atos command:

atos -arch armv7 -o TestApp 0x7556fb0

Where TestApp is your app name and 0x7556fb0 is the address you want to investigate. In your case that could be 0x883012.

Sometimes that could give you a class and a line number of where the crash happened. Like:

[Class methodName:]; -211

Another way that seem to work sometimes is to set up your app for HockeyApp. This way you can send the crashreports to HockeyApp and there you sometimes get more detail information. It is helpful to also upload the dSYM file.

Upvotes: 0

Hermann Klecker
Hermann Klecker

Reputation: 14068

At first set an exception breakpoint. If so, it may not show any useful output at the moment the exception is thown. But you should see the very piece of your code, where it is thrown. That helps a lot. If you then press "continue execution" in the debugger, probably two or three times or so, eventually the error message comes up in the debug console. By then, the main function may be shown but by then you have seen already, where the origin of the exception was.

Ok, nownig that have a look at all objects that you are dealing with in that very line of code. One of these objects (or any property of these objects) is supposed to be an NSDictionary, because, as the error message tells you, an "objectForKey:" message has been send but no appropriate selector was found. That is because the object in question is of type Boolean/NSBoolean.

You have most probabyl assigned some numerical object or pointer to something that is supposed to be an NSDictionary. It may well be that you are accessing an uninitialized pointer which just happens to point to some boolean type of thing. In that case the error may be hard to reproduce.

However, doing so will guide you onto the right track.

Upvotes: 2

Nickolay Olshevsky
Nickolay Olshevsky

Reputation: 14160

This exception should be easily debugged - search for all objectForKey: calls, and see where you can send this to boolean value.

Or, if you have too many lines of code with such call, you can symbolicate call stack: Symbolicating iPhone App Crash Reports

Upvotes: 0

Related Questions