views:

62

answers:

2

Hello,

I'm writing an application (basically its yet another iBooks clone) which consumes a lot of memory. Depending on the input data, it's memory footprint can go up to 70-80 MB (as MemoryMonitor states) or even more.
It works fine for quite some time, but it tends to increase its memory footprint over time.
So lets say you open a book and application's memory footprint goes from 6MB up to 60MB. Then what is supposed to happen is that you close the book and memory footprint goes back down to 6MB. And it doesn't. It goes down to ~30MB (according to MemoryMonitor), which results in a crash in just a few iterations.

Now the interesting part. I've tried clang static analyzer, but it shows no problems (apart from pointing at singletons etc).
I've tried using leaks instruments, but they show that I only have 2-3KB total (and it should be ~24MB+). Moreover, I'm not concerned that instruments are actually telling me the truth. I've double checked all the leaks that instruments report and I'm 99% certain that there are no leaks there.
I've tried using allocations instrument, but it shows that after closing the book, memory footprint goes down to 6MB, which is the desired number. But that doesn't make much sense since if it was the case, application would have never crashed. I've also tried using openglES profiler for Resource Bytes graph, but it also shows no leaking or anything else suspicious.
The only instrument I've used to trust was the Memory Monitor, because my application would always crash when it shows ~110MB real memory used. However, a) it doesn't show what allocates the memory and b) when I tried running it several times with the same application build, I found out that it's readings differ dramatically from run to run (15-20MB difference while doing exactly the same).

So all the instruments are telling me that my code is fine (apart from Memory Monitor, which appears to be correct but useless for any measuring) but it keeps crushing.
I have no clue what should I do next. I certainly cannot reduce the overall memory footprint anymore, and I cannot find memory leaks (which is still the way to go I guess).

So this are my questions:
1) Is there any way of finding leaks apart from those mentioned above? Another profiler program for iphone maybe?
2) I've read about some sort of defragmentation problems, like when you allocate/reallocate many objects and then application doesn't return freed blocks back to OS, which may can make it impossible to allocate big block of memory just because it is too fragmented and OS doesn't give you any more memory. I've never seen a good topic about that through. If anyone could spare a link to a related topic, that would be awesome.
3) I've tried disabling several parts of the program, and so far it looks like the whole problem might be coming from using CoreText framework. I'd like to hear from anyone who ever used this framework heavily and can confirm/deny that any problems exists there.
4) --any other suggestions--

P.S. I didn't include any code snippets because the code itself is pretty huge and I cannot reduce the amount of suspicious code to a reasonable amount.

A: 

The problem is, leaks only finds memory that is still retained that you don't have references to.

In your case you still have memory retained that you also have references to. As far as Leaks is concerned, it cannot tell if you meant to retain that memory or not so it says nothing.

In your situation, the best thing to do is to use the Object Alloc instrument - record a session, then for a region of growing memory alt-select the region, and select the "retained and still living" option on the side. Now go through the objects reported and figure out what is still retained that should not be - a good starting point is to look for any of your own classes still retained and figure out what you thought was deallocated.

The newer XCode also has a tool that combines leaks and object alloc, I can't say anything more since it's under NDA - but you may want to try that out. I don't know if you have to install it on a separate system to get access to the improved tools though...

Kendall Helmstetter Gelner
+1  A: 

A little silly perhaps, but when something roughly similar happened to me, I realized I had NSZombies enabled. Since then, my didFinishLaunching: has the following couple of lines at the top:

if (getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")) {
    NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
} else {
    NSLog(@"No NSZombieEnabled or NSAutoreleaseFreedObjectCheckEnabled");
}
Kalle
Blasted zombies! That was it! Amazing how much time I've spent trying to find out the source of that problem. I'm also surprised that memory allocation / leaks instruments ignore zombies as whole.
Alexey
They don't -- they turn them OFF, that's why they report so little. That was kind of the biggest hint to me in your text.
Kalle
I'm not certain that instruments turn them off. After I disabled them manually, Memory Monitor began to report completely different numbers, while readings from leaks/allocations instruments were still the same (I'm running instruments with allocations+leaks+opengles+memory monitor).That's why I think they ignore them rather then turn them off.
Alexey
Yeah, sorry -- LEAKS turns them off. I don't know about Memory Monitor.
Kalle