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

[Bryan M. <bra...@go...>]

Bob Rossi wrote:
> 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?
> 

The --suppressions option won't do anything to suppress memory leak
reports in Omega. If you are expecting leaks to be suppressed, don't
because they wont be.

Without having your program to play with, it's difficult to say. I am
certainly nervous that you might be getting false positives although for
a complete run, they are normally identified and discarded. I think a
cautious first step would be to find the leak reports that match the
malloc() shown by memcheck and see if they help you. Try to ignore the
rest for now. Once those are fixed (or you decide to ignore them) pick
one of the others and see if it is actually a real leak. If I had your
source, I would do this step but obviously, its your source, you are
familiar with it and it should take you a lot less time to determine if
it is a leak (not to mention, I don't really want to be signing NDAs etc).

If you find any false reports and can reproduce them, please let me know
in as much detail as you can so I can hopefully replicate it here and
fix it.



>> 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
>