[CMake] Custom memory checking result processing

[David Cole]

For the cmake valgrind dashboard, we use the script seen here:
http://www.cdash.org/CDash/viewNotes.php?buildid=647028

If you look at it, you will see that we list a bunch of tools that produce
valgrind output that we are not interested in having show up on the CMake
dashboard.

(For example, /usr/bin/gcc and /usr/bin/c++ are in the list...)

Then, we pass that to valgrind with the
--trace-children-skip=${valgrind_skip} command line flag.

Here's the catch: that's a custom build of valgrind that we have on that
machine that understands this flag. I think Bill Hoffman developed the patch
for that behavior and tried to submit it up to valgrind upstream, but there
was much discussion and no action, if I recall correctly.

Maybe Bill could chime in, or you could take up the question on valgrind's
mailing list....?


HTH,
David


On Fri, Jun 25, 2010 at 9:44 AM, Johny Jose <Johny.Jose at cern.ch> wrote:
>
> The frameworks in question are a necessary evil, we cannot do without
them, time and habit will not allow us to work with anything else i guess.
Well i guess i will have to try it out and see what comes of it, will let u
know how successful it is.
>
> Regards,
> Johny
>
>
> -----Original Message-----
> From: Marcel Loose [mailto:loose at astron.nl]
> Sent: Fri 6/25/2010 2:30 PM
> To: david.cole at kitware.com
> Cc: Johny Jose; cmake at cmake.org
> Subject: Re: [CMake] Custom memory checking result processing
>
> Well, I sort of ran into exactly the same problem that Johny describes.
> I devoted two mails on this issue to the CMake list --
> http://www.mail-archive.com/cmake@cmake.org/msg26858.html
> http://www.mail-archive.com/cmake@cmake.org/msg29155.html -- but got no
> response on either of them.
>
> In my case 'bash' is producing quite some noise; wouldn't want to call
> 'bash' flaky, though. But even if that weren't the case: you don't want
> to memory check your framework every time you run a test, only the
> program under test.
>
> There must be a better way to solve this, right?
>
> Best regards,
> Marcel Loose.
>
> On Fri, 2010-06-25 at 07:47 -0400, 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.)
> >
> >
> >
> >
> > Just my opinion,
> > David
> >
> >
> >
> > On Fri, Jun 25, 2010 at 7:18 AM, Johny Jose <Johny.Jose at cern.ch>
> > wrote:
> >         Dear all,
> >
> >         I am using valgrind to debug a framework which depends on
> >         several other underlying frameworks to function properly. As a
> >         result my memory checking turns up thousands of errors. I only
> >         want to see errors that arise from my framework. This is
> >         figured can be done by simply looking for a few regular
> >         expressions in the stack trace. Right now i am planning on
> >         creating a custom perl script which i will use as the
> >         memchecker instead of valgrind and send its output to CDash.
> >         Suppression files don't seem feasible as they don't have any
> >         sort of RegEx support and i have too many errors to list in a
> >         file creating ridiculously large logs and suppression files. I
> >         was wondering is there any better way to tackle this problem ?
> >
> >         Regards
> >         Johny
> >
> >
> >
> >
> >         _______________________________________________
> >         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
> >
> >
> > _______________________________________________
> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100625/022a205e/attachment-0001.htm>