CODEWITHSUNDEEP
iphonememory-managementmemory-leaksdebugginginstruments
EightyEight
EightyEight

Reputation: 3460

Leaks on the phone but not on the emulator?

Hey all, I have a problem and I'd like some advice.

I'm working on a document viewer that's composed of the following major parts:

  1. zip library which unpacks the document container (minizip)
  2. xml library which parses the document (libxml2)
  3. UI code which renders the document on screen

Nothing too complicated or fancy.

On the emulator, everything works beautifully; the viewer performs as expected. I've ran it through Instruments and there are no leaks. ObjectAlloc reports about 5.5 megs allocated over the lifetime of the viewer (that's repeatedly opening my test document over and over).

Unfortunately on the device (iphone 3G, iOS 3.1.2) things aren't as clear. Fairly frequently, repeated opening of the test file causes an out of memory error and the file will fail to open. Initial file opening always works. Even though emulator testing highlighted no leaks and the overall memory footprint was modest, I'm forced to conclude that there IS indeed a leak on the iphone (because why would repeated opening cause out of memory error).

I've attempted to run instruments on the device, but the app stalls (?!) half way through the run, so I actually had no success running Leaks.

I believe that there's a significant leak somewhere that only shows up on the device. So, I'm left with a two options (in no particular order):

As you can see, I'm reaching here. Is there anything obvious that I'm missing?

Thanks in advance guys.

Upvotes: 0

Views: 134

Answers (1)

kpower
kpower

Reputation: 3891

Maybe, you should try to run not Leaks, but Allocations Instrument on your device, and to search leaks with it (manually)?

+ (maybe this sounds stupid) Remove app from the device and repeat Clean-Build-Run with Leaks (why not?).

About manual leaks search.

Just start the Allocations Instrument and, while using your app, do every action for several times (for example - press button twice or more; navigate to some panel and back for several times - and so on). Memory should increase significantly only once or increase on action start and decrease on action end (of course, some divergences are possible, but they should be reflected with small amounts of memory). You will see it on graph.

Also make heaps (in Instruments' left panel while Allocations Instrument is selected there is a button for this) - they will help you to detect "still alive" objects that were considered as destroyed (there will be a lot of objects, but the first and easiest step is to check objects of your own classes).

Upvotes: 1

Related Questions