Gracefully Exiting

Member
Posts: 241
Joined: 2008.07
Post: #1
I have tried to be a good citizen and follow all the rules for retaining and releasing all of my objects.

I checked my objects by putting a breakpoint in the dealloc method but when I exit the program, the dealloc does not trigger. I exit the program by pushing the hardware button.

I am guessing that the AutoReleasePool is releasing everything but I'm not really sure.

I tried those instruments and they are hard to read.

There are also cases where I would like to exit my program through software interaction.

I have 2 questions:

1) Is there a good tutorial out there that tells how to make Instruments useful (other than the Apple docs).
2) Is there a proper way of gracefully exiting your program?
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #2
It's possible that your objects aren't getting deallocated. If this is happening on exit, that's fine, the memory is being returned to the OS anyway. There is debate among programmers as to whether you should deallocate objects before an application shuts down, even though that memory is freed anyway. I am in the camp that says you shouldn't deallocate an object if you don't need to.

(Lots of objects, like your Application delegate, for example, aren't going to get deallocated. )

Also, the autorelease pool isn't a magical object that cleans up memory without telling you. When you send the autorelease message to an object, the current autorelease pool gets a pointer to it. On the next cycle of the run loop, the autorelease pool simply sends that object a release message. If its retain count happens to go down to zero when that happens, that object is sent a dealloc message. So in the case of your autorelease pool sending an object its final release message, you would still break in your dealloc method.

On the iPhone, I don't see much of a use for exiting an application through any other means than the Home button. Any other way would be inconsistent with what the user expects.

To answer your questions directly:
1) I only use Instruments for Leaks. Not because the other features aren't useful, but I just haven't found a time when I need them. Run your application with the Leaks tool attached. Select the Leaks section from Instruments. It will check every 10-30 seconds for a leak automatically, but there is also a button for you to check leaks manually. Play around with your application, and check the leaks automatically. All of your leaks will appear in the lower table view. On the bottom of that window there is a little tab that says "Leaked Blocks". To the left of that, there is a drawer button. Click that button and a drawer will pop up on the right hand side of the window. Select each leak one by one, and you can see the stack trace for when that leaked object was created. Find any methods that you implemented in that stack track and double click on them, it should take you over to Xcode and show you the object that is being leaked.

Note that your method call will rarely be on top of the stack, and you will see a lot of confusing stuff in that stack trace. Just find the last time (the top most in that list) one of your methods was called.

2) In applicationWillTerminate:, you can perform some final clean up. Implement that method in your application delegate class. Like I said, you don't have to free memory in there, but closing down network connections would be useful.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #3
Excellent informative reply, I am grateful! So, what I gather from this is:

1) The only memory cleanup I should really be concerned with is runtime cleanup (ie, releasing textures between states).
2) The OS will reclaim any memory used by my program on shutdown.
3) The home button should be the only way to exit the game.

@end
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #4
Yup, all correct. To clarify, any allocation you make in memory that isn't meant to live for the entire scope of your application needs to be matched with a deallocation. For example, you have an Enemy class. Every time a new enemy appears, you create a new instance of this class. When this enemy dies, you should release that instance.

Just so no one stumbles upon this and thinks "Oh, I only have to release textures." But I think you got it. Smile
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #5
longjumper Wrote:2) In applicationWillTerminate:, you can perform some final clean up. Implement that method in your application delegate class. Like I said, you don't have to free memory in there, but closing down network connections would be useful.

You can also register a function to be called using stdlib's atexit(). Although, honestly, I'm in the "let the OS do it" camp, so I never cleanup on exit either.
Quote this message in a reply
Post Reply