I'm getting an EXC_BAD_ACCESS crash at startup and Xcode says the crash is at the NSApplicationMain line in my main.m file. The crash happens 99% of the time and when I run it with zombies enabled the crash never happens. Has anyone seen this before? How can I possibly debug this?
If you are running Xcode4 there default is to show very little of the call stack, move the slider at the bottom to the right. You may well not find any of your code but you should be able to get a good idea of what was going on. If it was a notification or selector after delay you will see that the Runloop dispatch and that will also give you a clue.
Finally, go old school, the way we did it in the day of coding forums, punch cards and only a couple of compiles a day: study your code. Know what every line of code does and why it is there.
As #Danra said, do run the Xcode Analyzer and fix all complaints.
The reason why running with zombies enabled resolves the bad access is probably that a) In this mode objects don't really get deallocated when their retain count reaches zero, and b) That your original crash is due to accessing an already deallocated object.
However with zombies enabled, instead of the crash I think you should see in the debug console the access to the deallocated object.
I also recommend using the static analyzer ("Analyze" in the XCode menus) in hope that it finds the culprit.
Related
I'm new to NSZombie but I have a problem with my app crashing with EXC_BAD_ACCESS. I'm having real trouble finding the object that is causing the problem. Looking online I followed instructions to enable zombie objects.
The problem I'm having has been reported by another person on that page. Enabling zombie objects stops the bad access error but gives me no information. Nothing is printed by NSLog. Is there somewhere else I should look, or am I doing something wrong? I don't really know my way round XCode or a Mac very well as I'm mainly a C# programmer.
Any help would be most welcome.
1) Run your app on Intruments.
2) In instruments, select Object allocations tool(automatically selected if you select leaks tool).
3)Click on the little "i" on top left, within the Allocations tool.
4) Select "Enable NSZombie detection".
5) Press the record button and let your app run.
6) Go through the execution of the app untill it crashes. As soon as there is a crash, you'd see a pop up saying that there was a EXC_BAD_ACCESS. Click on the little -> on the pop up to see the object that has turned into a zombie and the line of code responsible.
Sorry I am unable to upload a screenshot, as am at work.
Expand your project Executable and right click on it. and click on GetInfo->Argument tag aat end of the window you see plus and minus sign button click on + sighn button and write
Name Value
NSZombieEnabled YES
then after execute your project and whenever crash your application click on run munu-> console you see there why your application crash. please try this may be this will help you.
When my app crashes, instead of seeing what line caused, I see a window that prints all unreadable byte code. I used to be able to see what line it crashed on, but I must have changed something. Here's a screen shot:
What setting can I change to have XCode show me where my app crashed?
UNcheck the "Show Disassembly When Debugging" menu option:
The inverse of the above; if you want to show disassembly for the current debug location, you can use this drop-down menu:
The actual crash may not necessarily be in your code. The debugger is going to point you to the machine instruction that caused the crash. It may be in a cocoa-touch method or OS call which crashed because of a bad parameter you passed in (an invalid pointer is a common culprit).
Because the debugger does not have access to the source for the code that actually crashed, it will show you the disassembled machine code. What you need to do is follow the call stack backwards until you reach your code. That should point you to the line of code in your app which (indirectly) caused the crash.
I am relatively new to Xcode4 and I would like to know how can I identify a double release with it.
In the debugger I see a line like *** -[NSConcreteMutableData release]: message sent to deallocated instance 0x60b63fe0.
The problem is that knowing the address doesn't help a lot identifying the object and also the object type doesn't help too much identifying it.
I read http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/ but I did not found this to be too successful.
You can enable the NSZombieEnabled environment variable - see How do I set up NSZombieEnabled in Xcode 4? for instructions on how to do this on Xcode 4.
What this means is that released objects are kept around in memory, so the debugger can still find out the type of objects. When the crash occurs, you are told of the object in question.
The "Zombies" Instruments tool is great for detecting bugs of this type - it actually enables NZZombieEnabled and you can use it to find out exactly which line of code the crash occurs.
You can replace the release method using categories for testing purposes, this is not designed to work like that as part of the language but in the past I have found success it trying to do some testing, usually all you find out is that an autorelease pool is releasing you object.
You are sending a release message to something which already is released or having retainCount 0. Hence, its giving such an error message. Actually, my answer over here might help.
Use the profiler for Zombies to track down the actual object. It will automatically enable NSZombies and more importantly keep a history of all release and autorelease messages.
Use Profile menu command under Product.
In the profiling template selection dialog that appears, select Zombies.
Click the Record button in the toolbar (Command-R) to begin recording. Use your app normally. If a call is made to a deallocated object, a flag is inserted in the timeline pane and a Zombie Messaged dialog appears.
Click the focus arrow next to the zombie’s memory address to display the memory history of the zombie object in the detail pane, along with corresponding reference counts and method calls.
Here is the apple documentation with pictures:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/EradicatingZombies.html
Try using the property retainCount. If an object has a retainCount == 0 then it will be freed. Ultimately you will not be able to send it a release message.
I set a breakpoint immediately following these lines:
NSInteger index = [self.aCombobox indexOfSelectedItem];
NSString *nameSelected = [self.names objectAtIndex:index];
If I then roll the mouse over nameSelected, it shows a value of “nil.” And if I type “po nameSelected” in the debugger console, it says the string “does not appear to point to a valid object.”
So I added an NSLog to print nameSelected, which duly printed the string. And, once debugger is below the NSLog line, if I roll the mouse over nameSelected, it shows the correct value.
Is there some reason why the debugger behaves this way? It makes it harder to identify where the real problem is.
Me (and millions of other iOS developers) do this all the time and have no issues. Though it seems a stupid query, have you made modifications to the source while debugging (specifically, added lines of code)? If so, the debugger is still pointing to line X from the .o file while your source is out of sync.
The real answer is Tommy's comment to this old question of mine. It was a Xcode newby mistake. Sorry to have left this hang out there so long,
Actually, our experience is that the iOS enabled GDB is buggy as anything. We've observed these kinds of bugs quite often.
There might be a solution, but most of the time we just sucked it up and resorted to NSLog Debugging.
so i have a program i am developing and as im fairly new to objective-c and cocoa touch im not very familiar with the concepts of memory management in ipad app development. my problem is that my program keeps crashing without any warning and without telling me why, i turned on breakpoints and it shows an exc_bad_access signal. which leads me to believe that im not handling the memory properly. or its something else that i've over looked in my efforts. either way i need some help. if anyone can take a look at the app and tell me anything that may be causing it to act the way it is that would be great.
the point of the program is that it shows 20 mayan glyphs of the numbers 0-19, you drag the glyphs one at a time into the white 'drop zones' and it adds them and displays the result. however almost every time as soon as the second glyph is dropped in it quits, or it will display the answer and when you remove one of the glyphs to add another set it will quit then.
any help would be greatly appreciated. thanks stackoverflow :)
source files here
why don't you read Apple's documentation, which is reasonably excellent on this particular topic?
http://developer.apple.com/iphone/library/documentation/cocoa/conceptual/memorymgmt/memorymgmt.html
Get to know the debugger. At the point at which you see the EXC_BAD_ACCESS and the program halts, look at the call stack to actually see what the source of the signal was.
Also, in the case of an issue with accessing an object that has already been deallocated, it's useful to have NSZombieEnabled set to YES in your environment variables. To do that open the info panel for your executable (Groups & Files pane, expand 'Executables', and open the info panel for the executable your project builds) and in the "Arguments" add an environment variable named NSZombieEnabled with the value YES. With this enabled any objects which are deallocated are actually turned into an instance of a 'zombie' class which will allow you to catch any messages sent to those instances.