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.
Related
I am getting the following crash when I run the app on my device, but it works fine on the simulator:
Any idea of where I should probably start looking? This is super abstract to me
Also it seems that every time I run the app, I am getting a different error.
Here's a bigger image link
It might be because of zombie. Put the exception breakpoint in xcode and analyse.
In case if you don't know how to put exception breakpoint follow below steps:
Press cmd + 6 to open breakpoint navigator
Tap on "+" put present at the bottom left of the screen and select "Add Exception Breakpoint..."
Press Done.
Now run the program.
The program stops at the point where the exception is thrown. Analyse the problem and fix it.
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
I'm running my application on the simulator but as soon as it starts it just closes I guess it crashes, however I dont get any error message or reason why it's crashing, I'm running it as debug also, is there anyplace or anyway to get an error message?
Try switching to "debugger" view, and look at the console from gdb, if it crashes you will see the error, and hopefuly the call stack.
Example of crash message: EXC_BAD_ACCESS.
If you don't have the call stack visible, you can try to type 'bt' (for back trace) at the gdb prompt.
A lot of times when my application randomly crashes before launching, there is a problem in an interface builder file (such as a connection to a now non-existant object). Check your interface builder files to see any potential bad connections or errors and if you can't find any, put an NSLog in your applicationDidFinishLaunching method to see if the application is actually being started before it crashes.
In Xcode, choose Run menu, then choose Debug — Breakpoints On. Xcode should now point you to the location in code where your app crashes in the Debugger view.
I'm still relatively new to XCode. I'm trying to build an iPhone application and after my application didFinishLaunchingWithOptions method runs but not inside of any code I can find I get this error:
[58036:207] *** -[_PFArray release]: message sent to deallocated instance 0x17cd2fe0
I have no idea what that means apart from the fact that some array somewhere is being released when it's already released?
The real problem, is that I have no clue how to use the information provided there to find where the error is. There is no line of code to look in, no variable name, etc.
How do I use this information to find what I'm looking for?
try enabling zombies, then xcode puts a breakpoint automatically to the line where this error occurs. Google nszombieenabled for more information
Edit: Well, I don't have much thing to do so here your guide,
Open instruments. It is an application and you can find it in "~/Developer/applications/instruments" (in a default installation path). Instruments will be your right hand so master it well.
In the opening screen, you will see a bunch of templates. Open the one named "Zombies". Note: You will often use the template named "Leaks". It shows all the memory leaks you forget to release.
From "choose target" (top left corner), select "choose target", and again select "choose target". From here, browse the project directory, and choose "build/Debug-iphonesimulator/executableName". Here I assume that you have built your project in debug profile with nszombieenabled to true. If not, build it so and reply 3.
Press record button (top left corner). The simulator will appear and your app will start. Then reproduce the error you have encountered.
Instruments will interrupt the app showing a message bubble. Do not close the bubble. From the bar in the middle of the window, select "objects list" instead of "statistics". Now, all the objects allocated up to this point lies in a list sorted by their memory addresses. Here scroll down to the memory address written inside the bubble. You can type the initial letters for fast scroll. Then double click the line you found. This brings you to the code where the object is allocated IF THE CODE IS YOURS. If it is not, then ios allocated the object. But do not worry, and double click the lines below and above to see if they are allocated by you. This should give you a hint where may be the problem is since these lines triggered ios to allocate the object (possibly).
This is all I can say. I hope you can find what causes this error.
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.