views:

862

answers:

5

Hi

My app crashes after about 20 minutes with status 101 (Out of Memory, I believe)

Debugging using Instruments - ObjectAlloc and Leaks gives me no clues. The ObjectAlloc graph stays at a nice constant level of around 1 million bytes (1MB), as does the Net # of allocations. I have got rid of all leaks.

I thought it could be something to do with number of threads, but graphing these in ObjectAlloc also shows them to be constant.

Can anyone point me in the direction of another tool, or another avenue of investigation?

Thanks!

A: 

What do you mean by "nice level". It does not rise over time, at all? How much memory total - it could just be the phone needs some memory for some other app and yours is a little too big to stay up.

Kendall Helmstetter Gelner
No does not go up significantly, occasionally it rises when a new object is downloaded but you see it fall again when that object is released. The number of threads stays pretty constants the whole time.
adam
A: 

The error code 101 means that iPhone OS force quit your app. If you're using UIImageViews in your application, be sure to manage the memory on them. I've found that once my application goes over 10/12 MB, the iPhone terminates it.

If you're not using any image views (or large images), then your backend code is eating up too much space.

All I can say is you need to look at your allocation more carefully and manage what views you keep in memory at any one time.

Run your application in Instruments (Run -> Start with Performamce Tool -> Leaks) to see where your memory is getting allocated.

Hope this helps!

Sophtware
+3  A: 

Fix everything Clang finds. LLVM Clang Static Analysis

John Fricker
I have found that Clang is better at finding leaks than instruments. That's odd, I know, since Clang operates on code and instruments operates on the running program, but it's true -- I've had 0 runtime leaks reported even though some were definitely present.
Lou Franco
+1  A: 

Remember that objects allocated by the system (and that includes things like images and sounds) don't get tracked in Instruments (although the top level retain counts do, of course). So it's feasable that you're loading images, say, which won't contribute much to your memory usage as show, but can drain a lot of actual memory!

If none of this strikes any chords, you could try the subtractive debugging approach - (take a copy of your project) cut out chunks of functionality until the problem goes away or you get the smallest possible thing that reproduces it. That should at least help you to find where the bottleneck is. Admittedly this will be hard (a) because you'll have to wait 20 minutes or so every time you test (but if you make this a background procedure it's not so bad) and (b) because the nature of memory problems is that there may not be one single cause, but a critical mass of smaller causes.

Good luck!

Phil Nash
Ha. Yes I have been doing exactly this for days, and have narrowed down the problem to a certain part of code that indeed includes loading images. However, at one point the images were contributing to the graph in instruments and I managed to get that fixed. Maybe they are still hiding somewhere!
adam
A certain portion of the UIImageViews will contribute to the graph (that part that is in Cocoa itself). I believe the opaque CGImage data falls outside the scope of what Instruments tracks, however, so you may not have nailed it all.
Phil Nash
+1  A: 

My experiences with Object Alloc have not been that great. It does not always give you the actual memory used by your application.

Instead, use Object Alloc with Activity Monitor. Make sure you use the "Physical Memory Free" and "Physical Memory used" options in the activity monitor. That will tell you exactly how much memory your application is using.

lostInTransit