Re: [Valgrind-users] Omega - Release Candidate 1 Announcement

[Bob R. <bob...@co...>]

On Thu, Oct 05, 2006 at 08:12:57PM +0100, Bryan Meredith wrote:
> Bob Rossi wrote:
> > On Thu, Oct 05, 2006 at 07:01:31PM +0100, Bryan Meredith wrote:
> >> Bob Rossi wrote:
> >>> On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote:
> >>>> Fellow Valgrinders,
> >>>>
> >>>> please see http://www.brainmurders.eclipse.co.uk/omega.html for a
> >>>> complete overview of what this tool can do for you!
> >>>>
> >>>> (We use this heavily at work - feel free to give it a spin...)
> >>>>
> >>>> As ever, I would welcome your comments, bug reports and especially any
> >>>> news of success stories. Please share them with us on the list and copy
> >>>> me in so I don't miss them.
> >>> Hi, 
> >>>
> >>> I just installed valgrind with omega support. valgrind was reporting a
> >>> memory leak with the memcheck tool, and I spent a good 2 hours trying to
> >>> figure out if it was a leak or not, cause I couldn't find WHERE it
> >>> leaked.
> >>>
> >>> After running with the omega tool, I'm now confronted with 122
> >>> memory leaks, where as the memcheck was saying I only had 2.
> >> The results shouldn't be that different apart from the indirect leaks
> >> will also be reported each time. If this isn't because of indirect leak
> >> reporting, I have more work to do. Try running with "--instant-reports
> >> --show-indirect" as this will make the indirect leaks stand out a bit
> >> better. You might want to stick the output in a log file though :D
> > 
> > Would it be possible to not print the indirect leaks via an option?
> 
> You can try --instant-reports on its own (it wont show the indirect
> blocks without --show-indirect) and just use the on the fly leak reports
> to clue you in. This is set to only report on the first leak for a given
> allocation / leak location pair. I will look at splitting this out in
> the summary reports as well.

If I run like this:


> 
> > 
> >>> It looks like omega is not honoring the suppressions when reporting
> >>> on memory leaks, is this true?
> >> That is correct - I don't have suppression support in Omega.
> > 
> > Any plans on adding this? Basically, there are some memory leaks in our 
> > tool that are not going away any time soon. It is sort of a pain for
> > me to see them in the reports, cause it takes more time to sort through
> > what is fixable now, and what is not fixable. Also, when our nigtly
> > testsuite runs, when the suprressions are used, memcheck reports there
> > are no memory leaks, which is really helpful. We can say if things 
> > passed or failed off of this.
> 

If I run it like this:

LD_LIBRARY_PATH=$VECTORCAST_DIR/lib:$LD_LIBRARY_PATH
PATH=/home/TOOLS/valgrind-omega-svn-10-05-2006/bin:$PATH valgrind
--tool=omega --num-callers=20 --suppressions=clicast.supp
--instant-reports foo.exe > out-omega-instant.txt 2>&1

I still get massive amounts of memory leaks in comparison to memcheck.
Is this what you would expect?

> for some funky suppression types) but I have been focusing on getting
> Omega to give the correct results first.
> 
> > 
> >>> Can omega total the memory leaks that it found and report a number the
> >>> way memcheck does? That number usually provides a "wow factor" to people
> >>> explaining to there boss that they just stopped the coffee brewing 
> >>> network application from leaking 100 megs of memory each time a pot of
> >>> coffee is brewed ...
> >> Happy to include this for you - it will be in RC2.
> > 
> > Thanks!
> > 
> 
> Out of interest, has Omega helped you to fix any of the leaks reported
> by Memcheck?

To be honest, I've just started using it today, and I'm trying to
resolve these issues before I move forward.

Bob Rossi