What "Memory leaks" should be ignored?

[lionfly]

I have a project with about 2.2K Bytes memory leak, and can't get rid of it from analyzer, instruments, debugger etc.

I started a simple but unintelligent approach to check them out: I started a new blank project, to add each component one by one, and check the memory leak after each step.

Now I find the memory leak comes out even with only one blank Tab Bar Controller view in the executable, i.e. Malloc 144 Bytes, CoreGraphics, open_handle_to_dylib_path .

I then check the memory leak of Apple's example codes. For the LocateMe (LocateMe ), it has memory leak 144 Bytes in Simulator, 176 Bytes in iPhone Device. The screenshot of the Device memory leak is shown:

My question is: are there certain "memory leak" items unavoidable? What leaks we can ignore (e.g. if the leak does not increase more and more)?

Thanks for any suggestions.

[dcjones]

Hi,

I find it pays to run the analyzer, instruments, debugger etc from your device (iPhone) or whatever you have and not the simulator. You will get better results.

DCJ

[JasonR]

So far I've seen 2 cases that I think can be safely ignored:

1. Any leaks that only happen on the simulator.
2. Any leaks that only happen the first time you use an SDK object. NSURLConnection is notorious for this. Make sure you run the same functionality several times to make sure it only leaks the first time.

[noobdev]

Originally Posted by JasonR

So far I've seen 2 cases that I think can be safely ignored:

1. Any leaks that only happen on the simulator.
2. Any leaks that only happen the first time you use an SDK object. NSURLConnection is notorious for this. Make sure you run the same functionality several times to make sure it only leaks the first time.

Hi,

I just want to confirm, why would there be a difference in leaks depending on whether it's the phone or simulator?

That's a bit...scary...

[RLScott]

The process of detecting leaks is not an exact science. I can write some code that does not leak memory, but will appear to leak memory from instruments. All I have to do is have a hidden pointer to the "leaked" memory, and then, much later, release it through that pointer. An external observer has no way of knowing whether my program is capable of reclaiming that memory.

Use instruments and "build and analyze" as guides, but ultimately the question of whether you are leaking memory is dependent on whether you have allocated memory that you either cannot or will not ever release.

As was mentioned before, a one-time apparent leak is probably OK. But try very hard in testing to see if you can get such a leak to repeat indefinitely. If so, then you have something to worry about.