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.
There wouldn't be much market for AppCode if it didn't do something better than Xcode, so I'm sure you'll find at least a few areas where it does something for you that Xcode doesn't. Perhaps this is one of those cases.
On the other hand, the kind of leak that you've described should be pretty easy to spot using Instruments, so it's not like there aren't any tools included with Xcode that could help you find that kind of problem.
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!
Hello, Seamus. Clang does have support for this check, but it's
disabled by default (possibly because of
http://llvm.org/bugs/show_bug.cgi?id=8838 ).
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.
Related
I have just finished porting a decent amount of c-sources to the iOS platform and packaged them as a universal static framework. I, then, added the framework (not the project) to a sample iOS app in order to test linkage and proper function. That's when I ran into a humbling problem.
In my attempt to solve the problem described here, I also came across some symbols that are composed through the heavy use of macros (i HATE those). Some of those macros use function attributes that are really extensions of gcc rather than of standard C.
Of course I can always add -std=gnu89, but even then, I am not sure it will resolve the original problem of undefined symbols in the static library.
Not only that, I am now worried that my port to iOS of those sources may not be an accurate port and may result in the type of bugs/issues that maybe related to compiler's codeine and/or optimization policies.
If you can share some of your experience/advice in how best to go about that port, I would really appreciate it.
Thanks!
From manual testing with clang 8.0, it seems that both __attribute__((constructor)) and __attribute__((__constructor__)) work for your purpose.
I have an iOS project which has a static library and in the library there is a encrypt method and in the method it refers a lot of system encrypt method about AES encryption. When I build the static library with release,it returned the correct data.But when I build with debug mode,it returns nil.
What's the differences between the two modes？
The same source code can build out different binary files that works differently?
Help me,thanks beforehand. This is where I choose the two modes.
The main difference is the level of compiler optimization. Select the project target and look at the Build Settings and compare Debug to Release.
One potential reason for the crash is that the code has some memory usage errors that by coincidence do not cause a crash with code optimization but do with no optimization. Or there are some other configuration difference. See the comment by #iDev.
A starting point is to fix all warnings, both compiler and Analyzer. The examine the crash log to understand the crash. If you need help with that add a crash report to your question.
I've been running into a problem with Apple Instruments (4.6, Xcode 4.6.2 on 10.8.3).
Normally when using the Time Profiler, I can look at my source and see the hotspots without any problems (same project).
This time I've been trying to use the "Counters" Template to sample my CPUs Performance Counter Events. It samples the events as it should and I also have the same time based profiling information as well, however when I try to step into my code to look at the hot spots, like I can do for the "Time Profiler", all I get is "Unavailable" where I used to have the source. No Assembly either.
The Project is built as:
Release build
Debugging information is on and not stripped
DWARF + dsym is used to store the profiling data.
As I said, its the same configuration that works for the time profiler.
I already tried to (pretty much all that's stated in here: Xcode 4 Instruments doesn't show source lines , except for doing -O0, debug performance is not of interest to me)
recompile
relocate the dysm file using "File -> Re-Symbolicate"
As soon as I plainly close Instruments, start another Profile from Xcode and choose the Time Profiler, it works, if I go back to the Performance Counters, it stops.
Is this the default behaviour? Should it be like this? Has anybody already managed to get it working, in the current Instruments version? Otherwise it might be worth to file a bug with Apple.
Thanks a lot!
Try the Xcode 5.1 beta4. For me its fixed there: Counter works now.
The seed notes mentions some details what they did. Don't know if its under NDA.
I'm revisiting an an older project and converting to ARC, my first time through Xcode's conversion tool (Edit -> Refactor -> Convert to Objective-C ARC...), and I'm seeing a couple things that I'm not sure are real issues or red herrings somehow.
I get, as expected a big list of things that the tool finds that prevent it from completing, but:
Many (all?) instances of retain/release/autorelease appear to be flagged as errors e.g. "release is unavailable: not available in automatic reference counting mode". Am I really supposed to get rid of all these myself? I thought that's what the tool did.
In many of my classes, I'm seeing a bunch of errors that look like phantom parse/build errors that have nothing to do with ARC. E.g. in a simple class that apparently has no ARC-related issues, I'll get an "undeclared identifier" on some arbitrary method implementation, and then a bunch of "Parse error: expected }" at the end of the file, etc. These are not real-- the project builds fine, and I don't see any proximate cause or resolution for the errors.
There are "real" issues in the list as well (expected bridging issues that need to be explicitly clarified in code) but there are so many random errors of the above variety that it's hard to even find the signal in the noise. This seems wrong to me.
Am I misunderstanding what this tool is really doing? Apple's docs say this:
Xcode provides a tool that automates the mechanical parts of the ARC
conversion (such as removing retain and release calls) and helps you
to fix issues the migrator can’t handle automatically
Thanks.
The tool does not get rid of them for you, but simply adds retain/release code as need under the hood at the time of compile.
Those problems very well may go away when you get rid of old reference counting code.
EDIT: Further explanation:
In Xcode 4.2, in addition to syntax checking as you type, the new
Apple LLVM compiler makes it possible to offload the burden of manual
memory management to the compiler, introspecting your code to decide
when to release objects. Apple’s documentation describes ARC as
follows:
“Automatic Reference Counting (ARC) is a compiler-level feature that
simplifies the process of managing object lifetimes (memory
management) in Cocoa applications.”
In other words, ARC does not "strip" reference counting from your code, but rather does it on it's own under the hood. You no longer have to type release or retain or dealloc again. One thing the ARC needs to work is for it to do the reference counting entirely on it's own (with no user reference counting to "get in the way").
Took a long time to resolve, but both of these issues seemed to stem from some custom macros I was using. I had a macro for release-and-set-to-nil that I was using frequently, like this:
#define RELEASENIL(x) [(x) release]; \
(x) = nil;
I'm still not sure why, but for some reason, the ARC conversion tool didn't take this in stride, and choked on it, throwing the release warnings and the parse errors. (Some interaction with the preprocessor?) When I changed the macro to remove the release line, the conversion proceeded much more in line with my expectations.
And yes, it does of course remove the messages for you. (I'm answering my own question on the off chance that someone else ever has this issue.)
I'm trying to use Time Profiler, I've used it before.
I'm hiding system libraries, but all of my symbol names are HEX.
I'm running in debug, I have debugSymbols turned on....
I've restarted everything a few times and cleaned everything in between..
... anybody got any other ideas?
it's a bit of a pain because there are a number of variables that can cause this. some of the more common ones are:
sometimes you need to tell instruments where to find your files and/or symbols (Preferences->Search Paths).
have you enabled Link Time Optimization (LTO)? it should be off.
sometimes it helps if you do a clean/build.
sometimes it helps if you restart instruments.
in earlier versions of Xcode, it helped to use a central build directory.
verify that you are generating the proper level of debug symbols for all targets.
I no longer get this problem with the latest version.
Apple were no help in answering this for me - even though I used one of my Tech Support Requests. Must have had them stumped too.