Dr. Memory with OpenCppCoverage?

[Michał Fita]

Our project runs continues integration where unit tests project after build are run via OpenCppCoverage. The normal execution requires running the unit test executable invoked via opencppcoverage command (Windows).

We'd like to have proper memory leak checker on these unit tests, as the primitive mechanism hacked into Google Test which is based on _CrtMem* function doesn't play well with Google Mock (false positives due to expectations kept over lifetime of the test case).

Now the question is how to use Dr. Memory to avoid multiple runs of same tests executables? Should we call opencppcoverage to invoke drmemory invoking our executable? Or rather call drmemory to invoke opencppcoverage invoking our executable? But in former case how to avoid false positives potentially caused by opencppcoverage?

Thanks for the answer. If you can, please put these into FAQ.

[Derek Bruening]

I would start out by trying both nestings to see what happens.  Have you tried running either nesting?  Do they both work?  Do you know what technology is used by OpenCppCoverage?  If it's using binary instrumentation (like Dr. Memory), nesting such tools can be complex and may raise robustness issues.  Performance may also be poor depending on how dynamically modified code is handled: it's possible it's faster and simpler to do 2 separate runs of the 2 tools.  As you said, there may also be issues with the results from the tools from monitoring the extra binary.

Also note that Dr. Memory has a -coverage option which provides code coverage information using drcov.  I'm not sure whether its feature set meets your needs.

--

---
You received this message because you are subscribed to the Google Groups "Dr. Memory Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.