I'm having a problem with a Cocoa application I am writing. It has to parse a timestamped file that is updated every hour, and during testing it keeps crashing consistently at around 11:45 PM due to a segmentation fault. I'm assuming I must be messaging an object that has been deallocated. What tools are provided with the Xcode install to track object allocations and (hopefully) tell me if I am messaging an object that has been deallocated?
I am using Mac OS X 10.5.
I would recommend the following:
Use NSZombieEnabled to monitor when messages are sent to deallocated NSObjects
Use Instruments to track object allocations and/or memory leaks
The way I do it is by using a command line tool called gdb. Here is a tutorial on how to use it. You'll have to learn a few of it's commands, but once you do it's almost a pleasure to use.
Note: gbd can be used on C, C++, and Objective-C programs.
Have you run the program under gdb? This should allow you to inspect the stack and variables when it SIGSEGVs.
To track allocations, use malloc_history. This requires the MallocStackLogging environment variable to be set.
A quick point: using a deallocated memory location usually results in a EXC_BAD_ACCESS exception. If that's the crash reason you're seeing then you're correct in assuming it's a deallocation problem.
Run it in Xcode's debugger (which is gdb with a GUI on top) and reproduce the crash. Then, look at the stack trace.
Messaging a deallocated object usually has the top frame in objc_msgSend. The next step then is to run the app with NSZombieEnabled and reproduce the crash; the zombie will identify itself.
Related
My Mac app is crashing with exc_bad_access on the run loops.
So I enabled NSZombies, and Now I don't see such error as expected ( As the objects are not de-allocated).
But, I don't find any useful NSZombie Log in the console.
Is there a way to identify the issue ?
It's challenging. The most common cause of this error in Cocoa is directly accessing your ivars rather than using accessors. Accessors make the vast majority of memory crashes go away.
That said, they're not the only cause of memory errors. You may be accessing memory other ways. NSZombie does one specific thing: When you deallocate an object, NSZombie says "don't actually deallocate the object." Instead it turns the object into a zombie object that prints an error if you send it messages. But that only helps if the crash is due to sending a message to a deallocated instance. It could be lots of other things.
You should start first with the crash stack itself. Look up the stack and see what kind of object it might be, or who might be calling it.
Read TN2124, particularly the section on the BSD Memory Allocator, and the Enabling the Malloc Debugging Features section of the memory Usage Performance Guidelines. There are lower-level tools than NSZombie that you can use. MallocScribble is often the most useful. It overwrites deallocated memory with 0x55 so that you're more likely to crash sooner, and to make it easier to detect deallocated memory in the debugger. MallocPreScribble is useful for finding uninitialized memory, but this really only helps if you do raw malloc calls. ObjC objects are always pre-initialized.
And of course you have to put on your detective hat. What parts of your program are most suspicious? Are you doing multi-threaded work (that can cause memory crashes if you don't lock correctly).
If it reproduces easily, then you'll figure it out. If it only happens occasionally, well... I've hunted bugs like that for many months sometimes. Sometimes it's just hard.
You need to use memory profiler for that. Just build with Profile option and select Leaks.
I'm currently working on a game for iPhone/iPad using Cocos2D.
On the simulator it works fine and can run for hours, without any problems.
But on a device, it runs for some time and then just crashes out of nowhere. The debug console gives no error message, typing in "bt" just returns "No stack." and it doesn't generate a crash report.
It mostly crashes when loading the main menu or a new level but it can happen while playing a level as well.
Any ideas on how to debug this?
You should really read about memory management in objective-c
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
When I first switched to programming in objective-c (from C#/Java background), I had a lot of problems too. Once I understood memory management in objective-c, I rarely have those kind of problems. I don't use arc.
Whenever you alloc & init an object, the retain count is 1. You should remember to release these objects at some point. If you use other methods, then you get an autorelease object. That is the convention.
The time you will save is really worth it.
I'm newish to Objective-C and my memory management skills are not great. However, I haven't had a single problem until now. And now I've got big problems.
I've gone from zero crashes to crashing at random points, giving me either no console output or unrecognized selector errors on random types (-[NSCFSet isSameAsStop:]: unrecognized selector - I don't even use any sets and I surely have not called my custom isSameAsStop on any sets.). Judging by the randomness and errors, it seems like a memory thing to me although I'm not entirely sure.
How do I go about debugging this? The debugger assumes you know where your problem is... and mine is just everywhere. Ideas?
SOLUTION COMMENT
Some clarification on the solution suggestion to "run with zombie detection enabled":
Set the NSZombieEnabled to YES on the Executables' Arguments screen.
Build and then choose Run with Performance Tool > Object Allocations, which will start Instruments.
Click the "i" button on Object Allocations in Instr. and select zombie detection and retain counts.
Rerun and click around in your app, it'll tell you when you hit a zombie!
Thanks for the help!
You have a classic over-release bug on your hands. Somewhere, you are over-releasing an instance of the class that implements isSameAsStop and it just so happens that an NSSet instance is allocated at the same spot after the original instance is deallocated.
The first step is to "build and analyze" your code, fixing any problems that the static analyzer finds.
The next step is to then run with zombie detection enabled.
In Xcode: Build menu >> Build and Analyze
Finds a lot of common memory management issues.
I'm having a bug in my Objective C program which causes the machine to crash hip deep in some library methods, and it's all library methods down the stack to main (Which I haven't touched from the one XCode gave me). So, I have a bit of a mystery.
The error I'm getting is:
Program received signal: “EXC_BAD_ACCESS”.
Now, I'm sure that this means that somewhere I'm releasing something too many times, or something like that. This is the objective C version of a seg-fault, right?
My question is: Since it's not happening in my own code, is there some clever way of tracking down what I'm double releasing? or is code inspection the best bet?
thanks.
EXC_BAD_ACCESS essentially means that you're trying to access or use a specific chunk of memory in an unexpected way. For example, if you try to send a message to a memory reference that no longer represents a valid object. It's different from a segmentation fault, but related.
See this related SO question for suggestions on debugging over-released objects. NSZombie will work wonders for you. Once you get your hands on Snow Leopard (you're getting it this Friday, right?) use the Zombies instrument to simplify the process, and use the Xcode static analyzer to help you find such errors at compile time.
Also visit: http://www.cocoadev.com/index.pl?DebuggingTechniques and this Apple Tech Note.
As the title says, my app crashes when garbage collection is not enabled. The app pops up for a few seconds and then it just crashes, with nothing but this in the debugger console:
[Session started at 2009-08-17 15:03:20 -0600.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 12535.
unable to read unknown load command 0x22
unable to read unknown load command 0x22
unable to read unknown load command 0x22
unable to read unknown load command 0x22
I don't know why its happening. I think its probably a memory management issue. I used AnalysisTool (front-end to Clang Static Analyzer) to check for leaks and memory management issues, and I fixed the issues it found. Running the app through Instruments however reveals a memory leak around the time it starts. I have no idea where this leak is coming from...With garbage collection enabled the app runs fine, but Instruments still finds a leak.
Source code is available upon request
Thanks
Since the error says it occurs when calling [CFArray countByEnumeratingWithState:objects:count:] on a deallocated object, that gives you a fairly good idea of where to look. That method is part of part of NSFastEnumeration, so unless you're calling that method directly (highly unlikely), it is being invoked from within a for (... in ...) loop on your array object. If you can figure out where that is, you can set a breakpoint on (or just before) the for loop and check whether your object has been deallocated. The most likely cause of the problem is failing to properly retain the array, and it is probably released by the run loop draining an NSAutoReleasePool.
XCode has a bunch of memory profiling support built in - turning those on might reveal more information. I found these links particularly helpful:
http://developer.apple.com/technotes/tn2004/tn2124.html#SECMALLOC
http://www.cocoadev.com/index.pl?NSZombieEnabled
http://www.cocoadev.com/index.pl?DebuggingTechniques
http://www.cocoadev.com/index.pl?DebuggingAutorelease
You're probably releasing an object when you shouldn't, then sending it a subsequent message. unfortunately, the crash (where the subsequent message is sent) isn't where the problem is - it's where you are releasing (or worse, deallocing) where you shouldn't. The clang static analyser isn't foolproof, and blindingly following the advice won't necessarily have helped.
If it crashes after showing something for a few seconds, it may indicate that something that needed to be retained was released by the autorelease pool at the end of the run loop. Have a look at places where you assign variables with objects returned by other methods. Any method without "new", "copy", "alloc" (there's a few others I think) in the name usually indicates that you'll need to retain it if you want to keep using it.
It could also mean that you have released something that you shouldn't have and it was released again by the autorelease pool. Have a look at all the places you are releasing objects and make sure that you are only releasing objects that you have either retained yourself, or releasing objects returned by methods that explicitly state ownership, such as "new", "alloc", "copy", "mutableCopy" and so on.