Can't figure out memory leak testing with simulator and in general

Question

EDIT: guys, my question was about using the Instruments to see leaks, and the code as an example and side question, but you answered the side question and not the main problem.... Thank you for the answers, but I really need to find out how to work the Instruments with the simulator....

I am learning IOS development, In one of the codes I'm studying i think there is huge memory leak so I've tried learning how to use instruments. As i am learning right now, I am trying to use instruments with the simulator, but all the manuals i found are for connecting to a device and then using instruments and not with the simulator. every thing I've tried doesn't show any leaks in Instruments.

The app doesn't crash because i am guessing the memory leak is not that big, but when i am adding the following code it does crash, why is that, Even when i added the release every time, still crashes....what is wrong with the simulator? or with the code? working with xcode3, not 4.

for (int i = 0; i < 1000000; i++) {
    NSString *testLeak = [[NSString alloc] initWithString:@"test1223"];
    NSLog(@"%@",testLeak);
    [testLeak release];
}

And again, the app crashes and the simulator doesn't show any leaks, even when i put the "attach process" on "iPhone simulator".

Does it crash if you take out the `NSLog()` call? I can't imagine the logging system being happy about getting a million messages all at once. — aroth, Jul 23 '11 at 12:00
Yes, it crashes with or without the log....but when i take the release out, still can't see the memory leaking....I am trying to figure that out, not if the NSLog is crashing the app or not :-) thanks — Erez, Jul 23 '11 at 15:26

bbum · Answer 1 · 2011-07-24T00:12:54.520

NSString *testLeak = [[NSString alloc] initWithString:@"test1223"];

The problem is that you are not actually allocating anything. NSString is internally smart enough to recognize that the above expression does not need to allocate anything because the constant string @"test1223" can neither mutate nor ever be deallocated. Thus, it just returns that string.

If you were to NSLog(@"%p", testLeak); you'd see the same address over and over.

Change the NSString to NSMutableString and you'll likely see the thousands of copies. Maybe; NSMutableString could be optimized to just point to the immutable copy until a mutation operation is performed (implementation detail). Or you could allocate an instance of some class of your own creation.

Keep in mind that Leaks doesn't necessarily show you all leaks; it can't because of the way it works.

For this kind of analysis, Heapshot analysis is very effective.

If it is crashing as described, please (a) post the crash log and (b) file a bug with your app (built for the simulator) attached to http://bugreport.apple.com/.

In general Instruments + Simulator will not be terribly useful; the simulator is only an approximation of what is running on the device.

score 1 · Answer 2 · answered Jul 23 '11 at 12:14

1

[something release] doesn't actually free the memory the instant it is called - it just decreases the reference count of an object. If the count is 0, a [something dealloc] is called, and that frees the memory. I guess you are allocating memory faster than the system can free it... besides, doing 1.000.000 allocs in rapid succession instead of single huge one is probably as bad a coding practice as they come...

answered Jul 23 '11 at 12:14

Peter Sarnowski

11,900
5
36
33

Thanks, But as i wrote above, I am trying to figure out why can't i see the memory leaking in the instruments, not why is it crashing, that was the really side question....the problems is that i need to see that in the instrument happening before the app crashes, but can not seem to use the instruments with the simulator....thanks again :-) – Erez Jul 23 '11 at 15:28
In manual retain-release, the system will never lag in deallocation behind allocation, even under heavy load; the behavior is always immediately-dealloc-on-same-thread-when-retain-count-would-transition-to-zero. There is no race condition here (though, yes, very rapid allocation of this nature is always something worthy of analysis). – bbum Jul 24 '11 at 00:09

score 1 · Answer 3 · answered Jul 24 '11 at 01:09

It may be that some stuff is getting autorelease'd, and that is using a ton of the heap. Try changing your code to this:

for (int i = 0; i < 1000000; i++) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    NSString *testLeak = [[NSString alloc] initWithString:@"test1223"];
    NSLog(@"%@",testLeak);
    [testLeak release];
    [pool drain];
}

score 0 · Accepted Answer · answered Jul 24 '11 at 08:29

Thank you all, I actualy Found the answer around 4 am yestorday... when you want to test leaks on the emulator:

rum -> run with Performance Tool ->Leaks

If you select the simulator on the top right as the device to run the app on, It will lounch the simulator and the instruments and start the leak recorder, all in one click....

Have fun :-) Erez

Can't figure out memory leak testing with simulator and in general

4 Answers4