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.j...@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:lo...@astron.nl] > Sent: Fri 6/25/2010 2:30 PM > To: david.c...@kitware.com > Cc: Johny Jose; cmake@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.j...@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 > > >
_______________________________________________ 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