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

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 instr开发者_StackOverflow社区uments. 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".

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.

[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...

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];
}

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