When I bring up console after my iPhone app crashes, it often says "unrecognized selector sent to instance 0x blah blah blah." How can I find out what variable this is? Is there a way in the debugger? Is it even possible? Thanks.
In gdb you could type
po 0x12345678
to print the -description of the object at that address. But this info is seldom useful. You should instead check the backtrace of the exception first, which can locate the line of code that causes the problem.
It's very helpful to create an Exception breakpoint, and with Xcode 7.3, it's never been easier. This will help you find the line of code causing an exception.
add breakpoint on the line where the app crashes
click the breakpoint in the Project Navigator menu
find the breakpoint you just created and select it
click the "+" at the bottom left
Select "Add Exception Breakpoint"
Run your code...whenever you get a "unrecognized selector sent to instance 0x blah blah blah," the debugger will stop on the line that's causing the problem.
Related
I am getting a crash in my application which I am not able to trace out. In the log I am getting :
[CFString release]: message sent to deallocated instance 0xeb8a560
Even on debugging I could not trace out the crash. I placed breakpoints and enabled NSZombie but still not helpful. Does anyone have some idea for getting the location of crash?
for getting the exact location of crash, you need to add 'Exception BreakPoint' , that will add breakpoint to exact location where the crash occurs.
In the left side column of xcode 4:
tap on the breakpoint tab (the 6th tab over)
tap on the + button in the bottom left of the window
tap 'add exception breakpoint'
tap 'done' on the popup
reference "Run > Stop on Objective-C exception" in Xcode 4?
A string object over released. You can create an exception break point to find where it crashes. Also you can try using bt in GDB to get crash log.
This link lots of tricks and tips.
This type of error (using class retain/release memory management) can also be debugged using the Zombies Instrument. Often (not always) you can see the history of where the deallocated object was retained/released and figure out why is vanished out from under you.
I am trying to debug an EXC_BAD_ACCESS in my iPhone app. It is crashing on a method call and on the line of the method is EXC_BAD_ACCESS (code=1, address = xxx).
Before, I would have just used gdb info malloc-history <xxx> to start debugging, but I am having trouble finding a parallel command in LLDB.
I saw this thread that said to use Instruments, but when I do I still get the crash but I can't figure out how to tell exactly where the app is crashing from in Instruments.
I just need to figure out where this piece of memory that is crashing was pointing to. What is the best way to do this either using LLDB or Instruments?
You can see the malloc stack if you debug using instruments.
I encountered the same problem as you and similarly wanted to know how to get the malloc history when using lldb. Sadly I didn't find a nifty command like malloc-history found in gdb. To be honest I just switched my debugger over, but I found that annoying since I felt I shouldn't have to do that.
To find the malloc history using instruments:
Profile your project
Select Zombies from the list of instruments
Make your app trigger the problem
At this point you should be presented with the address that was already deallocated and you can explore it.
It should be a simple matter of viewing the malloc history at this point. I blacked out portions that had class / project names specific to the work I'm doing, but I think the essence and usefulness of how to go about getting this information is present.
A Last Word
The problem I ran into yielded a message like:
*** -[someClass retain]: message sent to deallocated instance 0x48081fb0 someProject(84051,0xacd902c0) malloc: recording malloc
stacks to disk using standard recorder
I was really puzzled where this retain was coming from since the code it was breaking on didn't have one (not in the getter or setter of the line it was on). It turns out that I was not calling removeObserver:forKeyPath: when a certain object was dealloc'ed. Later in execution KVO occurred do to a setter on a line and that blew up the program since KVO was trying to notify an object that was already released.
This problem is very easy to solve with an informative backtrace. Unfortunately with the latest version of iOS and Xcode, a good stack track is sometimes hard to come by. Fortunately you can set an 'Exception Breakpoint' in Xcode to allow you to examine this code prior to the EXC_BAD_ACCESS exception.
Open the breakpoint navigation in Xcode 4 (This looks like a rectangle with a point on the right side)
Press the '+' button at the bottom left and add an 'Exception Breakpoint'. Ensure you break 'On Throw' for 'All' exceptions.
Now you should get a full backtrace immediately prior to this exception occurring. This should allow you to at least zero in on where this exception is being thrown.
you can use command like this in lldb:
image lookup --address 0xec509b
you can find more commands at:LLDB TO GDB COMMAND MAP
Maybe is too late but for further assistance, on LLDB:
(lldb) p *(MyClassToPrint*)memory_address
E.g.
(lldb) p *(HomeViewController*)0x0a2bf700
1.When my app crashes and there's no message in console window Xcode shows me a green line with signature EXC_BAD_ACCESS or PROGRAM RECEIVED SIGNAL SIGABRT in the code editor. The question is: does Xcode always put this green line at the line of code where a bug is placed? If i see this green line put at the line
[myObject myMethod];
may i be confident that the bug should be searched for inside the myMethod function? Or maybe it may mean something else?
2.Sometimes this green line is put inside main.m file at the line
int retVal = UIApplicationMain(argc, argv, nil, nil);
Do you know what specific about placing the hint there? What does it mean?
3.Also sometimes the strangest thing happens: Xcode shows me a file with assembler code and the green line inside this code. Why? What should i understand when i see that?
4.If i repeatedly do the following: enter a screen, then do something, then quit the screen - my app crashes. It may crash at the second time or at the seventh one. What is the most common causes for such a crash? A memory leak? But Analyze tells me there are no leaks in my app. What do you think it may be?
As I said in another post :
In XCode, go to menu "edit scheme", choose the running configuration and add 'NSZombieEnabled' like in the picture below, when your apps crashes, it will provide you additional infos on the crash that should help you debug it.
Note that when your application debug is over, remove the NSZombieEnabled command as it impacts the application performances
The simple answer to point 4: The most common cause of a crash accessing deallocated/over-released memory.
You can check for NSZombies or debug any memory references that you can find in the error message.
You can find some hints here iPhone Xcode debugging
Regarding (3) I do not think there is a way to interpret that assembly code.
In Xcode, say you write an app for the iphone and it has a runtime
error in it. What I've been seeing is that it just closes out the
program in the simulator but doesn't really hilight or give me any
feedback as to what line caused the crash... am I missing something??
Note: I don't consider the console to be very effective since
it just spits out an error, but I still need to find where in
the heck that bug is stemming from in the code.
In the console, above the stack trace, it should say something like "[ClassName selectorName] unrecognized selector sent to instance".
Make sure you really meant to send that selector to that class. If you post what it is, we might be able to help more.
To access GDB, enable breakpoints, add one to your code by clicking in the line number gutter, press build and debug and finally open the debugger (CMD+Shift+Y).
Look in the console (command-shift-R).
You can set a global breakpoint on exceptions, which will let you trace the exact point at which they occurred. To do so, select the Run | Show | Breakpoints menu item in Xcode to bring up the breakpoints dialog. Select Global Breakpoints (so that this will be enabled for all of your projects) and create a breakpoint on objc_exception_throw in libobjc.A.dylib.
Now if you start your application by choosing Run | Debug - Breakpoints On, or manually enable breakpoints in the debugger window (Run | Debugger) before running, the application should halt at the point where the exception is thrown. You can then look at the stack trace in the debugger window, where it will highlight the particular line that caused the exception.
I'm learning iPhone programming from Erica Sadun's The iPhone Developer's Cookbook. When I run the app I created by following the steps in the Temperature Conversion Example starting on page 81 in the simulator, it terminates due to an uncaught exception. (See http://groups.google.com/group/iphonesdk/browse_frm/thread/6f44a90fdb8da28a?hl=en for the question I posted to the iPhoneSDK Google Group.)
The exception is thrown after calling UIApplicationMain() from my main(). If I look through the stack trace in the debugger, all I see is (of course) assembly. How do I find out what kind of exception was thrown?
Update:
Learning the details of the exception from the Debugger Console was enough to help me solve the problem. (See http://groups.google.com/group/iphonesdk/browse_frm/thread/6f44a90fdb8da28a?hl=en.) I verified that I could set a symbolic breakpoint on objc_exception_throw, but I didn't look to see if the backtrace from there would have been helpful.
Put a breakpoint at objc_exception_throw and run your app via Debug instead of Run
To clarify, what you're actually seeing when you get an exception without the breakpoint is the same stack trace always - it's the uncaught exception handler. The type of exception is logged to the Run console, but if you want to see a backtrace for where the exception was raised, that's what the breakpoint is for.
In the new Xcode (at least starting from v4.5), you can catch all exceptions easily by doing this:
Bring up breakpoint navigator (⌘6)
Click + on the bottom left
Add Exception Breakpoint
I think the above is the same as a breakpoint on objc_exception_throw. http://samwize.com/2012/09/26/xcode-4-dot-5-tips-and-tricks/
http://ijoshsmith.com/2011/11/28/debugging-exceptions-in-xcode-4-2/
Same as samewize's solution, but also shows how to make this breakpoint show up by default in all your projects (right click on breakpoint, Move Breakpoint To, User).
As Kevin answered, you will find more helpful debugging info by setting a breakpoint at objc_exception_throw.
If you are using Xcode 4.2, you can add this symbolic breakpoint by going to Breakpoint Navigator > Click on the add icon on the bottom left > Add symbolic breakpoint > Enter objc_exception_throw for Symbol > Done.