I am trying to debug a crash on my app
all i get is
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]'
I know its a problem with a fetch from CoreData that is returning nil.
Now my objective is to see where the crash is it coming from exactly.
I know there is a way to check with Instruments the exact line of code that causes my code to crash.
Could anyone point me in the right direction on which instrument would give me that information and some debugging tips when trying to find the line in Analyzer?
As per your error log, in my understanding you trying to insert nil value in NSDictionary/NSMutableDictionary. You can not pass nil as value or key into dictionary otherwise your code will crash.
My suggestion you debug you code using breakpoint, trace you execution stack i believe you will get your exact solution where your nil value inserting in dictionary.
If you want to find exact line of crash you can take help of debugger command. Enter bt (back trace command) in debugger window, it will give also same executed crash stack that give you instrument analyzer. Go through following links
https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_5_0.html
http://www.cimgf.com/2012/12/13/xcode-lldb-tutorial/
Related
I am parsing quite a large JSON model, and I have a LOT of objects set up to handle all the data. I recently added more data to the JSON model, to test it out, and I am getting this error
-[NSNull count]: unrecognized selector sent to instance 0xaed678
However, I need to know EXACTLY which function is crashing in order to fix it, but for some reason, xCode does not tell you where the function crashes which seems very odd, as that is very important information if you want to rectify the bug. Is there anyway for me to find out exactly which method or function caused the application to crash?
Thanks in advance
Set a breakpoint on unrecognized selector:
Creating breakpoint in Xcode for unrecognized selector
Then trace back in the code.
I have the following output from my app at the moment:
2012-09-14 11:55:32.558 projectname[2172:707] -[__NSCFBoolean isEqualToString:]:
unrecognized selector sent to instance 0x3ec4ba18
2012-09-14 11:55:32.570 projectname[2172:707] *** Terminating app due to uncaught
exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean isEqualToString:]:
unrecognized selector sent to instance 0x3ec4ba18'
*** First throw call stack:
(0x3263788f 0x3468d259 0x3263aa9b 0x32639915 0x32594650 0x41e47 0x417d3 0x46af7
0x320beefb 0x320bdfd9 0x320bd763 0x32061f15 0x325961fb 0x342faaa5 0x342fa6bd
0x342fe843 0x342fe57f 0x342f64b9 0x3260bb1b 0x32609d57 0x3260a0b1 0x3258d4a5
0x3258d36d 0x316e4439 0x3208ccd5 0x17e77 0x15ca4)
terminate called throwing an exception
I can see that the problem is that I'm trying to compare a BOOL to an NSString, the comparison is on data from a web service and it's always been BOOL before now. That's besides the point in this case anyway.
What information is in that log that can actually help me find the line of code that's causing the problem? I can see which instances (e.g. 0x3ec4ba18) are causing it but the log doesn't even tell me what type they are, let alone a line number.
Add an exception breakpoint by going to the exceptions pane (in the left sidebar), clicking the + and selection "Exception breakpoint". Then when you run the debugger will pause where the exception is actually thrown rather then when it is caught (or rather uncaught) at the top level.
There are many tutorials on this, Raywinderlich has one of good tutorial for determining crash from the console log..
Here you can get them..
My App Crashed, Now What? – Part 1
My App Crashed, Now What? – Part 2
After following these, come to know the specific reason of crash then google for this, you can resolve it easily.
When I start up my application I get the error detailed below. If I continue the application everything seems to be working fine. The error is raised between the calls to applicationWillFinishLaunching and applicationDidFinishLaunching.
I suspect the eror is getting generated when the xib is being loaded, however I can see nothing wrong with the xib and how it is connected up. Can anyone give me some tips on how I can trace back to find the source of the error?
Thanks,
2012-08-21 11:31:55.293 ConjugationViewer[32508:707] *** Assertion failure in -[NSTextFieldCell _objectValue:forString:errorDescription:], /SourceCache/AppKit/AppKit-1138.47/AppKit.subproj/NSCell.m:1564
2012-08-21 11:31:55.303 ConjugationViewer[32508:707] Ignoring exception raised in __-[NSPersistentUIManager restoreAllPersistentStateWithTalagentWindows:registeringAsReadyWhenDone:completionHandler:]_block_invoke_3: Invalid parameter not satisfying: aString != nil
I had same problem.
In my case I had set
[NSTextField setStringValue:nil] By mistake.
You can trace the problem in your code using crash stack log.
The log shows function call as stack start from bottom. You can search the last call of your function after which cocoa functions get called. You can say problem present at the same function.
How do I go about finding out where in my code caused the following exception?
2012-08-15 09:24:27.414 TestProject[82870:17303] -[TestObj doIt]: unrecognized selector sent to instance 0x1106f320
Best way to do it: Add a breakpoint to capture all exceptions, that will give you the line of code where you are getting the exception. From the console, you will get the same message you are posting on your question, so, use the pointer address to print the object that is getting the exception. If the object is garbage(the debugger wont print it), that means you are overreleasing an object. If you have zombies enabled, you will find a prefix NSZombie__ on your class name. That also means overrelease. If you get a different class than the one you are expecting, you are switching the objects at some point and sending a message to the wrong object.
Go to the breakpoints navigator (on the left)
at the bottom you have a +,
add an exception breakpoint on all exceptions
set a breakpoint for thrown exceptions. by default, it will pause when an exception is thrown -- there you will see the backtrace and values.
if it's completely random (e.g. not reproducible), then you may have best luck running Instruments with zombies enabled.
Ok. So I had this extremely weird SIGABRT error on a complex Objective-C iOS program that I'm working on, and after one day of tracking I found the culprit.
Let's say we have the following code:
NSArray *a = [NSArray arrayWithObjects:#"a", #"b", #"c", nil];
NSLog(#"tada: %#", [a objectAtIndex:-1]);
Why the hell will this terminate the program with Program received signal: SIGABRT and the debugger not even pointing to my code (but rather in some assembly part) instead of a nicer 'index out of bounds' and 'hey, this line of code here be wrong' error?
I thought I messed up the project config, so I reproduced this on a brand new project: same result.
Is there a way to configure XCode to be more nice and indicate this kind of errors in a more human understandable way ?
As the documentation says:
If index is beyond the end of the array (that is, if index is greater
than or equal to the value returned by count), an NSRangeException is
raised
And the default action, when no exception handler is defined, is to... well... you can see what the default behaviour is.
You can use #try/#catch to trap the exception, but that's not really Objective-C-ish. You know how many elements are in the array; there's no real need for you to be accessing elements that don't exist.
Exceptions like this normally have a stack trace, so you can go back to the line of code causing the error. (It might be worth switching between LLDB and GDB if it's not working correctly. LLDB is faster and smaller but not completely reliable.(
You should see something along the lines of "index of out range" if you look in the console log in Xcode. SIGABRT is the result of an assertion being fired. Sometimes you have to hit "Continue" after the crash in order to get the message to print.
The debugger tells you where the crash actually happened. It doesn't know what the original cause was. If the debugger leaves you looking at the assembler, just move up the stack until you reach your code.