What memory leak may the Xcode Analyzer not notice?

I am afraid that asking this question may lead to some downgrades, but after some research that does not satisfy me, I decided to take a chance and ask more experienced people ...

There are many questions here related to some specific issues related to the XCode Analayzer tool. This is a very useful solution. But I would like to ask you - as a newcomer to the iOS world - which memory management tools cannot be seen with this tool.

In other words, are there any general aspects of memory management that iOS beginners should think about "Oh, be careful with this, because in this case Xcode Analyzer may not warn you about your error" ...

For example, I found here Why can't the Xcode static analyzer detect non-running stored properties? which:

(...) the analyzer cannot reliably detect problems of saving / freeing the border of the method / library (...)

Sounds good, but maybe you know about some other common problems ...

+8
debugging memory-leaks xcode analyzer
source share
1 answer

The analyzer is very good at finding routine leaks that hit new programmers writing non-ARC code (failures to call release , returning objects with the wrong hold count, etc.).

In my experience, there are several types of memory problems that it does not find:

  • Usually it cannot identify strong link loops (aka save loops ). For example, you add a repeating NSTimer element to the NSTimer controller, not suspecting that the timer maintains a strong reference to the view controller, and if you do not invalidate timer (or do it in the wrong place, for example, the dealloc method), neither the view controller nor the timer will be released.

  • He cannot find errors of circular logic. For example, if you have circular links, where the view controller A represents the view controller B, which in turn represents a new copy of A (instead of rejecting / popping up to return to A).

  • He cannot find many problems associated with counting memory. While working with Core Foundation features, it gets better if you have code that does manual memory allocation (for example, via malloc and free ), a static analyzer can be limited in use. The same is true when using the count code without a reference (for example, you are using SQLite sqlite3_prepare_v2 and you cannot call sqlite3_finalize ).

I am sure that it is not a complete list of what it does not find, but these are common problems that I ask about Stack Overflow, for which the static analyzer will have limited help. But the analyzer is still an excellent tool (it also detects problems other than memory problems), and for those who do not use ARC, it is invaluable.

Having said that, although the static analyzer is an underestimated first line of defense, you really should use the Tools to find leaks. See Troubleshooting memory problems in the app in the Instruments User Guide. This is the best way to detect leaks.

+7
source share

All Articles