-
Notifications
You must be signed in to change notification settings - Fork 283
Exception when searching for headers in src and sources in .libs directory #508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our < 8000 a class="Link--inTextBlock" href="https://docs.github.com/terms" target="_blank">terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I am working on a smaller example that would be much easier to reproduce on your side, will notify when done |
Do you run gcovr in the same directory as the compiler? |
I run gcov in root of repo directory, there are multiple directories in which compiler is runned. I prepared branch with minimal setup required, all commands to reproduce 3 errors:
All test descriptions are in check.sh, should be very easy to recreate, all additional dependencies are stripped, o just keep most of original files, directory structures and Makefiles.am. I'm getting same error in this example as in original repo mentioned in issue topic. Please try to recreate and if you need any more assistance, please ping me. |
Gcovr should be called from the same directory as the compiler to get the correct source paths. |
Sure, let me test that. Just a heads up, in this repo i have files cpp and h which have the same name, but they are in different directories and they expose content in different c++ namespaces, so from compiler point of view there is no conflict here. I will try to test given branch and will get back to you. |
From this branch, i don't get exception but just some warnings:
|
This behavior was introduced with 5.0 (fc67f18) if the source file can't be found. |
The problem is that GCC writes the file path relative to the working directory and gcovr tries to get the correct path. Can you run gcov from the same directory as the compiler and let gcovr collect the files? |
Sure. So let's take a meta/ directory from the repo, if i call gcovr inside that directory, i don't get any errors, but only 4 files are visible on output:
other 3 files are still not visible which are in SAI/meta directory
and corresponding *gcno files are also in that directory, but executing gcovr from SAI/meta gives those errors:
not sure why it searches those ins ".libs" directories, that's really strange and there is also future question, im planning to add unit tests to this projects, and test will be located in another directory, but they will link with precompiled *.a files and execute from tests directories, so question here would be where the actual instrumentation data will be updated? This also exposes another question, since for example headers can have code itself, for example templates code, or explicit default constructor. So if header is used in 2 different directories, where would be his instrumental data included? And when gcovr should be run in this case? |
Probably the same issue as in #386. Problem is probably a combination of the following factors.
These problems naturally only manifest in more complex projects, so it is challenging to debug. Since GCC 9 the |
Thank you for exhausting explanation and actually this project is compiled with g++ 9.3. I will have to figure out a way from smaller examples and probably manually shuffle gcov output files to specific directories. Just wanted to avoid that :) |
@kcudnik Branch coverage on C++ code is a really tricky subject. Please refer to our FAQ entry Why does C++ code have so many uncovered branches?. Note that No idea about the missing line coverage for the one argument though. It is not always intuitive how the compiler associates code with lines if a statement stretches multiple lines. And by “not intuitive” I mean “I don't understand this either”. So it's best to not read too much into these coverage metrics. They're great for directing your attention towards code that is under-tested, but 100% coverage is a rather problematic goal. |
@latk Thanks for detail explanation, i already found that article which in detail explains this problem. Thank you for your input. Agree on coverage goals, but sometimes you have someone higher in the latter that have only % numbers in mind, not actually representing nothing. I can write C code with 3 different bugs which will cover 100% and will not have any branches :) |
@kcudnik Can this be closed? |
is the proposed fix already on mater branch? |
Do you mean the |
I reduced 1 level of directories, but still get same issue, currently im using patch that was suggested but i would like to see fix on this repo too |
I'm not sure if this will help in this specific case, but there are quite a few issues in this repo where it might help. I had a bit of trouble getting gcovr to work with multiple build directories, and sources/header being in different directories. What worked was passing |
Sure, what do you need to check me exactly? We are currently using gcovr 5.0 with gcc-11 and I can run our coverage builds with or without |
Can you check the PR branch with and without |
Is this issue still not solved with latest master branch? |
We are currently using 5.2 and it works again |
Closing because problem is solved. |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
when headers are in different directories then sources, i get this error:
header exception:
Notification.h is located in lib/inc/ not in lib/src
source exception:
SaiInterface.cpp is located in lib/src not lib/src/.libs/
To Reproduce
Steps to reproduce the behavior:
I added exclude for /.libs/ since this is another bug, gcovr somehow search for cpp files in /.libs/ directory, not sure why, you can run without this exclude and you will get other error
Expected behavior
Everything should work fine
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context
Some files like SaiInterface.cpp are actually reused (compiled explicitly to different projects, you would need to check Makefile.am, I'm in process of refactoring sairedis library to reuse each file only once, and maybe this would help. Please reply to this issue if more data is needed. I'm currently working on code coverage for sairedis repo.
The text was updated successfully, but these errors were encountered: