After updating from 4.1 to 4.2, gcovr fails to generate files as before update #364

Verequus · 2020-04-21T16:49:37Z

I've been trying to update the gcovr module from 4.1 (which works fine) to 4.2, but that doesn't work correctly. The setup is basically like this: For every module we want to run gcovr the folder structure is like:

<module>
+src
+test/UT

Inside UT the makefile is called both to compile the files as well to execute the tests. gcovr is called from this directory with this:

"py -m gcovr --object-directory=../../{0} -r . --html --html-details -o coverage.html --html-title \"Coverage Report for {1}\" --print-summary".format(source_dir, module_name)
"py -m gcovr --object-directory=../../{0} -r . --xml --xml-pretty -o coverage.xml".format(source_dir)

where source_dir = "src" and "module_name" is the name of the module.

Since 4.2 changed the meaning of "--html" and "--xml", the call like this fails already. So I reordered the calls to this:

"py -m gcovr --object-directory=../../{0} -r ../../{0} --html-details -o coverage.html --html-title \"Coverage Report for {1}\" --print-summary --html".format(source_dir, module_name)
"py -m gcovr --object-directory=../../{0} -r ../../{0} --xml-pretty -o coverage.xml --xml".format(source_dir)

This ends up with an empty coverage.html, where instead the directory reference from "../../src" is "." instead and the source file to be analyzed neither longer appears in the main file nor as its own file (see in
coverage.zip each html file respectively - the xml files are similar).

If I try to use the "--html" and "--xml" parameters by adding "coverage.html"/"coverage.xml", the result does not change, only a warning about ignoring "--output" appears.

What do I have to do to make this work again? Or is this actually a bug in gcovr 4.2?

The text was updated successfully, but these errors were encountered:

latk · 2020-04-22T21:26:21Z

I am quite confused by this setup, both by how things used to work and how things subsequently broke.

The --object-directory flag almost never does what you want, but is one way to provide a search path for the .gcda/.gcno files. But here you're pointing it to your src directory?
The --html and --xml flags were changed to take an optional argument. That was not strictly backwards-compatible. However, your original commands are not ambiguous? How did things fail after the update?
-r ../ style invocations are only fixed/supported since recently, so there could be bugs. This parameter does many things, but mostly it's just a default filter. I'm therefore not sure how things could have worked previously, as . would be test/UT and only contain the tests but not the code you're trying to cover?

Please provide the following information so that I can understand this setup:

given source files like src/code.c and test/UT/test.c, where do the object files end up?
Are they all compiled by test/UT/Makefile? Or is there a separate Makefile for src?
In those Makefiles, how is GCC invoked? From the same directory, or is a cd involved?
You are running gcovr with test/UT as the current working directory, right?

It would also be helpful if you can run gcovr in --verbose mode, as that provides lots of info about which .gcda files are found and which source files are excluded by some filter.

Verequus · 2020-04-28T16:21:52Z

Sorry for the delay, work was very busy.

To dispel your confusions:

--object-directory points to src, because the .gcda/.gcno files for the source files are in there (yes, we still have no separate folders).
--html and --xml are indeed innocent, I thought initially it was the cause and never noticed that the issue persisted regardless of order of parameters. So I'll keep the order of parameters as it is.
I did try to change -r . to -r ../../src but that failed to provide the correct paths (can't quite remember now what the issue was now). So if the call worked for gcovr 4.1 by chance, I don't know why it would fail now.

The other four points:

The object files are in the same directory as their respective source file (src and test/UT).
Both src and test/UT are compiled by the same test/UT/Makefile.
I'll paste the relevant part of the makefile below:

MAKE=mingw32-make

TARGET=UT_modulename
SRC_UT=$(wildcard .cpp)
SRC_MODULE=$(wildcard ../../src/.c)
OBJ=$(SRC_UT:.cpp=.o) $(SRC_MODULE:.c=.o)

%.o: %.cpp
$(CXX) -c -o $@ $< $(CXXFLAGS)

%.o: %.c
$(CC) -c -o $@ $< $(CFLAGS)

$(TARGET): $(OBJ)
$(MAKE) -C <various Mocks (not included in coverage)>
$(CXX) -o $@ $^ $(LDFLAGS)

run: $(TARGET)
$(TARGET).exe --gtest_output=xml:testresults.xml

Yes, test/UT is the current work directory from where make is started.

I have also created log-4.1.txt and log-4.2.txt. They have redacted to protect the innocent, but the essential parts have been left.

Verequus · 2020-06-02T12:05:23Z

Friendly reminder to look into this. :)

Spacetown · 2020-07-12T21:53:49Z

It's difficult to reprocuce without a complete examle. I've tested a little bit with the informations.
The test:

all:
	&& $(CXX) -fprofile-arcs -ftest-coverage -fPIC ../../src/main.cpp -o testcase

xml:
	.testcase
	$(GCOVR) --object-directory ../../src -r ../../src --verbose --keep --xml --xml-pretty -o ../../coverage.xml

gives an empty XML file. This is because the coverage files are generated i 8000 n the test/UT directory and searched by default only in --root and --object-directory.

Removing --object-directory ../../src and adding an positional argument . as search path for gcov files will result in an on empty output file.

Also changing to:

all:
	cd ../../src&& $(CXX) -fprofile-arcs -ftest-coverage -fPIC main.cpp -o testcase

xml:
	./../../src/testcase
	$(GCOVR) -r ../.. --verbose --keep --xml --xml-pretty -o ../../coverage.xml

gives a file with data.

Spacetown · 2020-09-02T20:11:26Z

@Verequus Can you test this with the current master branch? For me it looks like the problem solved with #410.

Verequus · 2020-09-03T12:50:53Z

@Spacetown The build environment is depending on a wheel release package like provided on PyPi. How do I create one? Or can you attach one for me?

Spacetown · 2020-09-04T20:01:31Z

@Verequus I had to look for it first this because I've never done this before.
Clone the current master and run following command in the root directory of the clone:

python setup.py bdist_wheel

This will create the wheel file in the distdirectory.

Verequus · 2020-09-08T16:33:50Z

I've tried now to create this distro, but setup.py doesn't seem to support bdist_wheel as parameter. There are a number of other options related to bdist, but none seem to be relevant.

Spacetown · 2020-09-08T18:25:40Z

Can you post the error message? I've tried the command on MacOs and the wheel file was generated.

Verequus · 2020-09-09T08:16:32Z

$ python setup.py bdist_wheel
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help

error: invalid command 'bdist_wheel'

The "python setup.py --help-commands" results in help.txt. I run Win 10 with Python 3.6.8, if that matters.

I don't think it makes really much sense to investigate why it doesn't work for me, if I only need the wheel package you can create. Please attach it here.

Spacetown · 2020-09-09T13:34:51Z

As I mentioned, I'm using a Mac. The wheel is a binary distribution depending on the OS and the used python.
It seems that you haven't installed the wheel package.

python -m pip install wheel

Verequus · 2020-09-14T15:10:13Z

Managed to get around doing that test, but no change to the results when running the UT job.

Spacetown · 2020-09-17T18:43:41Z

@Verequus Can you upload a smal make with sources to reproduce the error?

Verequus · 2022-01-19T13:27:26Z

So by chance a colleague of mine figured it out. We had to add a new parameter. From only (irrelevant other parameters redacted)

--object-directory=../../{source_dir}

to

--object-directory=../../{source_dir} --filter ../../{source_dir}

Leaving this for posterity.

Verequus mentioned this issue Apr 22, 2020

Python 3.8 breaks network drive setups #365

Closed

latk added Filters related to filters, include/exclude, path handling Type: Question labels Apr 22, 2020

Spacetown added a commit to Spacetown/gcovr that referenced this issue Jul 12, 2020

Add test for gcovr#364

f2b6602

Spacetown added a commit to Spacetown/gcovr that referenced this issue Jul 22, 2020

Add test for gcovr#364

332214d

Spacetown added a commit to Spacetown/gcovr that referenced this issue Jul 23, 2020

Add test for gcovr#364

99d66ef

Spacetown added a commit to Spacetown/gcovr that referenced this issue Aug 1, 2020

Add test for gcovr#364

c80e92b

Spacetown added a commit to Spacetown/gcovr that referenced this issue Aug 14, 2020

Add test for gcovr#364

ec0c870

Spacetown added a commit to Spacetown/gcovr that referenced this issue Sep 13, 2020

Add test for gcovr#364

518582a

gsmithufl mentioned this issue Sep 18, 2020

[gcov] gcovr 4.2 breaks gcov plugin - project source files missing from html report ThrowTheSwitch/Ceedling#449

Closed

Verequus closed this as completed Jan 19, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

After updating from 4.1 to 4.2, gcovr fails to generate files as before update #364

After updating from 4.1 to 4.2, gcovr fails to generate files as before update #364

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

After updating from 4.1 to 4.2, gcovr fails to generate files as before update #364

After updating from 4.1 to 4.2, gcovr fails to generate files as before update #364

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!