On 6/25/2010 7:47 AM, David Cole wrote:
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of
valgrind errors, do you really want to be depending on them?
(Serious question, not trying to be flippant... It would make me very
nervous to depend on a framework that has more than a handful of
valgrind issues: and each issue would have to be something that I was
convinced did not have a high likelihood of occurring in real world
usage scenarios.)
So, lots of things that you have to use like libX11 have tons and tons
of valgrind stuff in them. Some are not real, some are, but you still
have to use those libraries as they are. What you do is create a
valgrind suppression file. What I usally do is run valgrind with
--gen-suppressions=all. This makes valgrind spit out the exact text to
put in the suppression file. This output will show up on the dashboard.
You use that to create a suppression file that you pass to valgrind.
Then you set this in the cache:
MEMORYCHECK_SUPPRESSIONS_FILE:FILEPATH=${CTEST_MEMORYCHECK_SUPPRESSIONS_FILE}
CTEst will then use that as a suppression file. You keep adding to the
suppression file until you have it like you want. Many times it is the
same thing over and over, so a few suppressions go a long way.
-Bill
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
