Should the static analyzer provided by Xcode 4.3 catch or flag ivars that are not de-allocated?
I’m relatively new to iOS development and I’m looking for some enligthenment: My team builds our project with static analysis enabled for debug builds in XCode. To evaluate AppCode’s inspection feature, I performed an inspection on the entire project.
While I expected AppCode’s inspection to be good, I did not expect that it would find 50+ instances of ivars that were not being de-allocated correctly because we have static analysis turned on in Xcode. We verified that AppCode had correctly identified the issue, in a couple cases this resolved known memory leaks.
Should the clang static analyzer have caught these?
I’m hoping its because some project settings haven’t been correctly set. As I’d expect the clang static analyzer to at least flag missing de-allocations.
Got the answer from the clang mailing list and clang can catch this issue. The problem is that the version of clang that ships with XCode has this feature disabled!
I agree that Instruments would identify a leak or leaks, and in fact it had. However the process of narrowing down the source of a leak or, more likely, leaks is rarely easy in my experience. The issues AppCode flagged ended up resolving two known leaks the team couldn’t narrow down. Additionally it revealed many others that were part of the known issues and others that were unknown.
Once clang is updated it should also nail these kinds of issues.