Figure 4-6. An example of calling a method on a deleted object in Objective-C

Generator QR Code 2d barcode in Objective-C Figure 4-6. An example of calling a method on a deleted object

Like I said, this one isn t as common, but it s important to be aware that it can happen so that you at least look for it once you ve exhausted other options.

This kind of mem stomp is a lot harder to have happen in Objective-C than C/C++ because of the reference counting of pointers that takes place. Using retain and release means that objects that are still needed don t get deleted too soon. However, it s quite easy to get this to happen in C/C++ when you re dealing with callbacks and function pointers, and you can get it to happen in Objective-C if you re not managing your memory properly.

The most common place I ve run into this kind of mem stomp is with animation systems. The usual sequence of events is something like this: 1. 2. 3. 4. 5. 6. 7. 8. 9. Object A creates an animation instance. Object A sets a callback to itself so that it is notified when the animation completes. Object A triggers the animation. The animation runs. The animation completes and calls Object A s callback. Inside the callback, Object A causes an app state change that requires that the animation gets deleted. The animation object gets deleted. The callback completes and returns into the animation object (which has now been deleted). The animation object does some cleanup code, which involves modifying some member variables.

10. What it s actually doing is changing memory that has been allocated to something else now. I have typically run into these kinds of problems when transitioning between front-end menu screens and in-game state (and vice versa) in games. It s not uncommon for an animation to play in response to user input and at the end of the animation trigger a state change. For a simplified example, see Figure 4-7. Of course, this kind of mem stomp can occur in other ways, so just be aware of it.

Mem stomp bugs are fairly rare, compared to other kinds of bugs, but they can be the most difficult to track down and fix. One of the important first steps is learning how to recognize when something might be a mem stomp. However, it is also important not to leap to the mem stomp conclusion too soon. Look for the simple explanations first. Then if you can t find a simple explanation, start looking at the harder ones. Here are a few things to look for that might indicate a mem stomp: The app suddenly crashes, but the crash happens at a different point each time you run the app. (This could also indicate a timing/threading problem or could indicate multiple different crashes.) The app behaves in a random, incorrect manner after consistent events. (For example, your game starts with a random, nonzero score every time you load into the game from the menus.) Unexpected values show up in variables after unrelated events. (For example, game state data changes after you load an image into memory.)

You see the following message show up in your console: malloc: *** error for object 0 XXXXXX: Non-aligned pointer being freed (see the Enable Guard Malloc section for more information). CAUTION: A memory stomp won t always cause a crash. Oftentimes it will just cause strange behavior. If the stomp writes a valid value into some other variable, the program might not crash; it might just behave erratically. During the development of Dapple, I ran into a strange problem: upon entering the game, playing for a short time, and then quitting back to the main menu, sometimes one of the menu items would show up in white, as shown in Figure 4-8. It turned out to be a stomp being caused by a callback returning to the animation system after the state change from in-game to the front end had occurred, after the animation system had been deleted. The animation system was stomping over an image object in memory.

Figure 4-8. An example from Dapple of the strange behavior that can occur as a result of a memory stomp