|
From: Bryan M. <om...@br...> - 2006-09-23 16:50:29
|
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...) >From the web page: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Omega addresses what I perceive to be one of the few shortfalls of the excellent Valgrind Memcheck Tool - where Memcheck reports the location that a leaked block was allocated, Omega also shows where it was leaked. In RC 01 =3D=3D=3D=3D=3D=3D=3D=3D removed the need to patch VEX in order to work. It also closes off some false positive cases (seeing a =93Welcome back to the block=94 message wh= ile using =96instant-reports should hopefully be very rare now). Whilst this patch is pretty well on the money, some of the changes have resulted in a performance hit and there remains at least one edge case that you might be able to trip (I'd like to know if you can trip it with a trivial example please). The rest of the release candidates will examine what can be sped back up without compromising the output. 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. Please =96 go forth and find leaks! (and report any bugs :D) thanks and happy hunting, Bryan "Brain Murders" Meredith |
|
From: Bryan M. <bra...@go...> - 2006-10-04 20:40:42
|
Fellow Valgrinders, I have just moved ISP from eclipse to demon. Therefore, Omega is now hosted here: http://www.brainmurders.demon.co.uk/omega.html ----- Nick - would you update link on the patches page for me please? I haven't had any feedback at all on this :( surely someone has tried it and either it worked or it didn't? Please, post on the list so I know how you got on. Happy Hunting, Bryan "Brain Murders" Meredith |
|
From: Nicholas N. <nj...@cs...> - 2006-10-04 22:12:27
|
On Wed, 4 Oct 2006, Bryan Meredith wrote: > I have just moved ISP from eclipse to demon. Therefore, Omega is now > hosted here: > > http://www.brainmurders.demon.co.uk/omega.html > ----- > > Nick - would you update link on the patches page for me please? Sure. Do you want your email updated to the googlemail.com one above as well? Nick |
|
From: Bryan M. <bra...@go...> - 2006-10-04 22:23:15
|
Nicholas Nethercote wrote: > On Wed, 4 Oct 2006, Bryan Meredith wrote: > >> I have just moved ISP from eclipse to demon. Therefore, Omega is now >> hosted here: >> >> http://www.brainmurders.demon.co.uk/omega.html >> ----- >> >> Nick - would you update link on the patches page for me please? > > Sure. Do you want your email updated to the googlemail.com one above as > well? > > Nick > that would be great - thanks. Bryan |
|
From: Bob R. <bob...@co...> - 2006-10-05 13:37:17
|
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. It looks like omega is not honoring the suppressions when reporting on memory leaks, is this true? Also, I was only trying to fix the "definatly" lost instances of memory leaks that memcheck found. Then I was going to turn on leak checking in the nightly test suite. At that point, I could then continue to fix the rest of the memory leaks memcheck found (ie. indirect lost). So, two more questions. Why does omega find so many more memory leaks than memcheck? Are they real leaks or false positives? 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 ... Thanks, Bob Rossi |
|
From: Bryan M. <bra...@go...> - 2006-10-05 18:01:39
|
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 > > 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. > > Also, I was only trying to fix the "definatly" lost instances of > memory leaks that memcheck found. Then I was going to turn on leak > checking in the nightly test suite. At that point, I could then continue > to fix the rest of the memory leaks memcheck found (ie. indirect lost). > > So, two more questions. > > Why does omega find so many more memory leaks than memcheck? > Are they real leaks or false positives? See above for indirect leak reporting. Apart from that, its hard to tell without having the source available in order to work out why Omega generated the leak report. > > 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, > Bob Rossi > Thanks for taking the time to try my tool and tell me about it. Bryan |
|
From: Bob R. <bob...@co...> - 2006-10-05 18:42:42
|
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? > > 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. > > 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! Bob Rossi |
|
From: Bryan M. <bra...@go...> - 2006-10-05 19:13:04
|
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. > >>> 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. I would like to add suppression support in (and have a couple of ideas 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? Bryan |
|
From: Bob R. <bob...@co...> - 2006-10-05 20:23:43
|
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 |
|
From: Bryan M. <bra...@go...> - 2006-10-05 23:17:23
|
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 > |