In general using ASSERT_* is not a big deal for valgrind unless the test is actually failing. Valgrind reports on what the program did not what it could have done. So if you are failing on an ASSERT_* then you have a unit test failure which you need to address. The memory leak caused by the failure should not concern you nearly as much as the failure itself. Once you fix the failure the leak should no longer be reported by valgrind.
If the unit tests pass that means you did not hit any of the ASSERT_* cases. If you are still reporting memory leaks then they were caused by the code being tested not by gtest exiting early. Understanding the behavior of ASSERT_* vs EXPECT_* is important for leaks reported by static analysis tools like Klockwork and Coverity those tools report on what could happen not what actually happened. That is a different subject than valgrind. George -----Original Message----- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Saturday, September 2, 2017 11:03 AM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] dealing with (reported) memory leaks and valgrind > Some, maybe the majority, of the leaks are not that critical. As a > major example, the security unittests have a whole bunch of reported > leak failures as a result of invoking the googletest framework macro > ASSERT_TRUE. This has come up more than once on stack exchange: how do I clean up if a gtest assert fails. The answer is pretty much - you don't; if you needed to, you chose the wrong form of assertion in your code. Here's googletest itself on the subject: === Assertions Google Test assertions are macros that resemble function calls. You test a class or function by making assertions about its behavior. When an assertion fails, Google Test prints the assertion's source file and line number location, along with a failure message. You may also supply a custom failure message which will be appended to Google Test's message. The assertions come in pairs that test the same thing but have different effects on the current function. ASSERT_* versions generate fatal failures when they fail, and abort the current function. EXPECT_* versions generate nonfatal failures, which don't abort the current function. Usually EXPECT_* are preferred, as they allow more than one failures to be reported in a test. However, you should use ASSERT_* if it doesn't make sense to continue when the assertion in question fails. Since a failed ASSERT_* returns from the current function immediately, possibly skipping clean-up code that comes after it, it may cause a space leak. Depending on the nature of the leak, it may or may not be worth fixing - so keep this in mind if you get a heap checker error in addition to assertion errors. === So assuming the code has chosen correctly when it uses ASSERT, there's not much to do. I do not know how to teach valgrind not complain; since they're macros, and valgrind operates at runtime level where is has no idea of macros that vanished at preprocessing. _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
