Testing Code with Instruments - Xcode 4 - page 434

{
// Override point for customization after application launch.
[self.window makeKeyAndVisible];
NSTimer *theTimer =
[NSTimer scheduledTimerWithTimeInterval:1.0
target:self
selector:@selector(timerDo)
userInfo:nil
repeats:YES];
return YES;
}
- (void) timerDo {
NSObject *theLeak = [[NSObject alloc] init];
}
This code creates a timer that repeats once per second. The timerDo timer handler method creates a new
object called theLeak , which is never released. When the pointer is overwritten, the memory is lost and
becomes a leak.
If you build and run the project, as shown in Figure 16.9, the app appears to work. The window has no UI ele-
ments and does nothing. But the app doesn't crash, and there's no indication that it's leaking memory. If you
leave it running for long enough, it eventually causes an iOS memory error. But because theLeak is a small
object, it's difficult to distinguish the leak from other possible crash events, unless you monitor memory direc-
tly.
FIGURE 16.9
There's no way to tell from the Simulator or from the build messages in the editor that this app is leaking memory.