<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [CMake] Custom memory checking result processing</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Thanks for the suggestions, but i already went down these paths. The problem is my logs in xml format on an average go above 100 MB of output, with gen-suppressions i get 300MB output files and the suppressions file generated out of these is again way too big for my liking.<BR>
If only valgrind had more features in terms of expressing suppression rules like some sort of pattern matcher which would suppress all errors except the matching ones it would have been easier, because the errors i want to look at match a contain a particular pattern. Right now the only workaround is manually parsing the xml log file and selecting the errors i want to see. I used to have problems viewing these results too on CDash because of the huge file sizes.<BR>
Using a generated suppression files even if i optimized it with wildcards is not feasible since i have no way of knowing which errors i don't need but i do know which errors i do need. It would be a really great feature to add to valgrind.<BR>
<BR>
Regards,<BR>
Johny<BR>
<BR>
-----Original Message-----<BR>
From: cmake-bounces@cmake.org on behalf of Bill Hoffman<BR>
Sent: Fri 6/25/2010 4:17 PM<BR>
To: cmake@cmake.org<BR>
Subject: Re: [CMake] Custom memory checking result processing<BR>
<BR>
On 6/25/2010 7:47 AM, David Cole wrote:<BR>
> I can't really think of a better way to tackle the problem...<BR>
><BR>
> But I will make this one observation:<BR>
> If these underlying frameworks you depend on produce *thousands* of<BR>
> valgrind errors, do you really want to be depending on them?<BR>
><BR>
> (Serious question, not trying to be flippant... It would make me very<BR>
> nervous to depend on a framework that has more than a handful of<BR>
> valgrind issues: and each issue would have to be something that I was<BR>
> convinced did not have a high likelihood of occurring in real world<BR>
> usage scenarios.)<BR>
><BR>
<BR>
So, lots of things that you have to use like libX11 have tons and tons<BR>
of valgrind stuff in them. Some are not real, some are, but you still<BR>
have to use those libraries as they are. What you do is create a<BR>
valgrind suppression file. What I usally do is run valgrind with<BR>
--gen-suppressions=all. This makes valgrind spit out the exact text to<BR>
put in the suppression file. This output will show up on the dashboard.<BR>
You use that to create a suppression file that you pass to valgrind.<BR>
<BR>
Then you set this in the cache:<BR>
MEMORYCHECK_SUPPRESSIONS_<A HREF="FILE:FILEPATH=$">FILE:FILEPATH=$</A>{CTEST_MEMORYCHECK_SUPPRESSIONS_FILE}<BR>
<BR>
CTEst will then use that as a suppression file. You keep adding to the<BR>
suppression file until you have it like you want. Many times it is the<BR>
same thing over and over, so a few suppressions go a long way.<BR>
<BR>
-Bill<BR>
_______________________________________________<BR>
Powered by www.kitware.com<BR>
<BR>
Visit other Kitware open-source projects at <A HREF="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</A><BR>
<BR>
Please keep messages on-topic and check the CMake FAQ at: <A HREF="http://www.cmake.org/Wiki/CMake_FAQ">http://www.cmake.org/Wiki/CMake_FAQ</A><BR>
<BR>
Follow this link to subscribe/unsubscribe:<BR>
<A HREF="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>