views:

1916

answers:

5

When i try to check leaks of my iPhone App using Instruments, everything is just fine. Same App on actual real device shows this leak for a few times during the app launch. It is pretty non-deterministic and it happens in system libraries. I tried to google down the solution without a luck. Anyone experiencing the same problems? Anyone knows the solution?

I find interesting, that every of my leak in code will crash the app sooner or later. These GeneralBlock-3584 leaks keeps app perfectly stable. Might this be reason for AppStore rejection?

Thanx for any answer regarding this undocumented problem (Apple is silent unfortunately).

+2  A: 

Leak detection tools can often yield false positives, especially in underlying system libraries.

I am familiar with these "leaked" GeneralBlocks, and they didn't cause an App Store rejection in my experience.

IANAASRW**, but I think you're fine.

** I am not an App Store Review Wizard

amrox
A: 

I got this kind of leaks too,haven't find the solution yet.Besides that,everything works fine.

aquaibm
A: 

There are leaks in the Apple frameworks. Specifically the HTTP classes. You should raise a radar defect report.

Roger Nolan
+5  A: 

You have nothing to worry about, this is false positive from Instruments.
It has to do with freeing resources of the thread that has being terminated. They are just laying around until next thread is done and cleans resources after the one of the previously terminated. Instruments take this for a 'leak' but it's the feature of pthreads implementation on the iPhone OS which in perfect world would be handled differently. More on this on the Apple's dev forum here and here.

zakovyrya
A: 

Do you have UserDefaults that you hadn't gone into Settings to initialize during those, "first few times," you ran your app?

I saw the same problem - app was (relatively) clean on the latest Xcode/Simulator (the usual pair of 128 byte mallocs were there - but that's purely a Simulator problem with UIViews). Once I ran it on an iPod Touch, I saw the GB3584.

However, after going into Settings and changing a setting (which forced the save*), the problem went away.

  • I am using Apple's sample code for UserDefaults to properly read those settings without having to first go in and change something.

So, it may very well be nothing. If you can confirm that a visit to Settings cleared it up, then we'll know where to start looking for leaks (or where to direct Apple to look).

inked