Since builds on master currently fail the valgrind step, here's my proposal for the temporary way forward:
1. request that the failure threshold on the valgrind step be bumped up. That way all of the reports remain visible until the team decides how to deal with this (see other emails). 2. If you have a change to master that is failing and you need to get it through you can rebase your change on this revert from Phil: https://gerrit.iotivity.org/gerrit/#/c/22301/ That will allow the change to build, since the test environment will not save one memcheck file which contributes 8 fails, enough to put the count back under the limit. the Jenkins log for your build will now not show all of the memchecks, unlike the note in #1, but should pass if nothing else is wrong. === Longer term we have to decide whether the memcheck results are worth having contribute to the jenkins vote. I've seen a fair bit of comment on the Internet that suggest gtest and valgrind don't make a really good combination, although there are certainly others using them in concert as we're trying to do. If they are, we will have to write suppressions for things we decide are not errors important enough to count towards a fail. There's a way to do that, but I have no personal experience with it. Basically, you examine everything, decide what you want to suppress, and then, using a text output file instead of an xml one: Run valgrind as usual, but with the extra option --gen-suppressions=all. This tells valgrind to print a suppression after every error it finds You then clean that up and using your list, add the ones you want to the suppression file (the current one lives in iotivity/tools/valgrind/iotivity.supp) _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
