MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010931CMakeCTestpublic2010-07-02 12:312016-06-10 14:31
ReporterJason Nye 
Assigned ToZach Mullen 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010931: Ctest code coverage fails when files in different directories have the same name
DescriptionI'm not sure if this is a ctest error or a gcov error. We encounter constant ctest errors when we have header files that have the same name but are in separate directories, i.e.:

${CMAKE_SOURCE_DIR}/a/b/c.h
${CMAKE_SOURCE_DIR}/g/h/c.h

The symptom we are seeing is as follows:
When ctest attempts to load the c.h files for coverage, it gets the wrong file (I'm guessing paths are being stripped somewhere). I think it knows there are two c.h files, it just loads the same one twice. Ctest will actually get a premature eof on parsing one of the c.h files because it apparently only stores the length of one of the files and when reading the c.h that has a smaller size, it fails because it is expecting to read more data.

If the files have a different number of lines (which they normally do), one of the files' lengths is used and ctest will fail with a premature eof when attempting to load the other.

The error is printed from cmCTestCoverageHandler::ProcessHandler and the message is: "Problem reading source file ...".
Steps To Reproduce
Additional InformationThere is already a bug submitted (ID 2796) that has been there for quite some time, but we've found the root cause -- the same file name in different directories confuses either ctest or gcov (I think it is ctest).
TagsNo tags attached.
Relationships
related to 0002796closed David Cole ctest code coverage end-of-file issue 
Attached Fileszip test.zip (2,603) 2010-07-13 13:36
https://public.kitware.com/Bug/file/3241/test.zip
gz test.tar.gz (1,510) 2011-01-12 14:35
https://public.kitware.com/Bug/file/3619/test.tar.gz
txt log.txt (1,616) 2011-01-12 14:35
https://public.kitware.com/Bug/file/3620/log.txt
Issue History
Date ModifiedUsernameFieldChange
2010-07-02 12:31Jason NyeNew Issue
2010-07-13 09:21Bill HoffmanStatusnew => assigned
2010-07-13 09:21Bill HoffmanAssigned To => Zach Mullen
2010-07-13 10:10Zach MullenRelationship addedrelated to 0002796
2010-07-13 13:36Zach MullenNote Added: 0021387
2010-07-13 13:36Zach MullenFile Added: test.zip
2010-07-21 17:47Jason NyeNote Added: 0021445
2011-01-12 12:39Jason NyeNote Added: 0024628
2011-01-12 13:59Jason NyeNote Deleted: 0024628
2011-01-12 14:33Jason NyeTag Attached: Repro project
2011-01-12 14:34Jason NyeTag Detached: Repro project
2011-01-12 14:35Jason NyeFile Added: test.tar.gz
2011-01-12 14:35Jason NyeFile Added: log.txt
2011-01-12 14:36Jason NyeNote Added: 0024631
2012-01-12 16:47Sean McBrideNote Added: 0028281
2016-06-10 14:28Kitware RobotNote Added: 0041721
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0021387)
Zach Mullen   
2010-07-13 13:36   
I tried to reproduce this error using a small test project which I've attached. The problem is that for my small project gcov is only generating coverage files for the cxx files, not for their corresponding header files. Do you know why this is happening / how I can make gcov create coverage files for the headers?

Also, I've confirmed that this bug doesn't happen with .cxx files:

http://www.cdash.org/CDash/viewCoverage.php?buildid=663844&status=2 [^]
(0021445)
Jason Nye   
2010-07-21 17:47   
Our header files have code in them (i.e.: a class with inline member functions). The source files include the corresponding headers without the full path (telling the preprocessor to get them from the current directory).

We've also been adding the following two compiler options to tell the compiler not to inline anything in debug builds:

-fno-default-inline : Prevents gcc from inlineing functions defined inside a classs scope (but they will still have linkage like inline functions)
-fkeep-inline-functions : emit any functions linked as inline functions into the object files (causing them to be compiled even if they aren’t called)

Note that the issue occurs whether or not the flags are set; these flags may
simply help you get coverage data for the headers a little more easily.

Thanks for looking into this!
(0024631)
Jason Nye   
2011-01-12 14:36   
Just uploaded a minimal project to repro the issue. This was run on ubuntu 10.04.

Please continue to investigate.
(0028281)
Sean McBride   
2012-01-12 16:47   
This sounds like 0011717.
(0041721)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.