Why doesn't gcov report any lines being covered by my unit tests?

cocoa xcode code-coverage ocunit gcov
user23743 picture user23743 · Sep 6, 2009 · Viewed 7.2k times · Source

I am using Xcode 3.2 on 10.6, with the shipped version of gcov and default GCC compiler (both version 4.2.1). I have created a dependent Cocoa unit test bundle which is injected into my app, and followed Apple's documentation on setting up a gcov-instrumented build configuration - based on the Debug configuration which doesn't have any compiler optimisations enabled.

When I build the test bundle with this 'Gcov-instrumented' configuration, the app launches and the tests are injected and run. Also the coverage statistics files are generated at:

build/<AppTarget>.build/Gcov-instrumented/<AppTarget>.build/Objects-normal/x86_64/<object>.gcda

build/<AppTarget>.build/Gcov-instrumented/<AppTarget>.build/Objects-normal/x86_64/<object>.gcno

So far so good. I know the tests are really being run because if I insert failures then the test suite fails as expected. Unfortunately, gcov reports that no lines of the objects have been covered by the tests! Every line is reported as 0 coverage. I've searched here and at the Apple mailing list archives, and can't find anyone with a similar problem. I expect I'm missing something - but what is it?

Answer

danielpunkass picture danielpunkass · Oct 12, 2009

I have been running into this problem intermittently. I stumbled into a good length of lucky time where it was "mostly working" in my main project. By mostly working I mean I was able to get coverage to show up, but with a little more pain than on 10.5. I had to aggressively delete the coverage files and rebuild in order to get any updates, for instance. Even in my "barely working" state, the compiler/runtime doesn't seem willing to overwrite an existing coverage data file.

I think I've stumbled back on to a working scenario. Voodoo for sure, and less than ideal:

  1. Make sure the SDK is 10.6.
  2. Make sure the deployment is set to gcc 4.0 (!).
  3. Do a full clean of the project.
  4. Rebuild.

Does this get you the expected coverage data?

Granted, I would expect to be able to generate coverage files that work using gcc 4.2 or one of the LLVM compilers, but for the moment this seems to have me slightly less crippled than before.

Another clue: when I observe the coverage data (using Google's Cover Story), I get warnings like:

/BUILDRESULTS/MarsEdit.build/Code Coverage/MarsEditDataModelTests.build/Objects-normal/i386/MEDataItem.gcno:version '400A', prefer '402*'

But the coverage information is still presented. So it seems it's balking at an older coverage format version, but if I use the newer compiler (4.2) which would presumably generate the newer format .gcno files, the 0% coverage problem plagues me as it does Graham.

Related questions

Xcode build failure "Undefined symbols for architecture x86_64"

An Xcode beginner's question: It is my first experience with Xcode 4.6.3. I am trying to write a very simple console program, that searches for paired BT devices and prints them to an NSLog. It builds with the following error: Undefined …

Read More
Hidden Features of Xcode

With a huge influx of newbies to Xcode, I'm sure there are lots of Xcode tips and tricks to be shared. What are yours?

Read More
"Unknown class <MyClass> in Interface Builder file" error at runtime

Even though Interface Builder is aware of a MyClass, I get an error when starting the application. This happens when MyClass is part of a library, and does not happen if I compile the class directly in the application target.

Read More