|
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:43
|
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: Dirk M. <dm...@gm...> - 2006-10-04 21:19:29
|
On Wednesday, 4. October 2006 22:40, Bryan Meredith wrote: > 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. I've tried it, but it just crashed on all examples I tried (konqueror. openoffice, a few smaller apps). I didn't investigate further. Dirk |
|
From: Bryan M. <bra...@go...> - 2006-10-04 21:46:38
|
Dirk Mueller wrote: > On Wednesday, 4. October 2006 22:40, Bryan Meredith wrote: > >> 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. > > I've tried it, but it just crashed on all examples I tried (konqueror. > openoffice, a few smaller apps). I didn't investigate further. > > > Dirk that's a start - x86 or x86_64? What version of gcc do you have on your system? How does it crash? How did you run it? If you can get me started with those answers, I can start to investigate and hopefully fix the problems. I have come across an interesting bug but its in a large C++ program and I haven't had enough time to reduce it yet. It revolves around constructors that are invoked before main() is called. Thanks for the feedback, Bryan |
|
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:16
|
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: Dirk M. <dm...@gm...> - 2006-10-04 23:11:37
|
On Wednesday, 4. October 2006 23:46, Bryan Meredith wrote: > that's a start - x86 or x86_64? x86 > What version of gcc do you have on your system? gcc 4.1.3 > How does it crash? it crashes during exit, leaving a big useless core file behind: #0 0x3804d102 in ?? () (gdb) bt #0 0x3804d102 in ?? () #1 0x38012594 in ?? () #2 0x00000001 in ?? () #3 0xdeadbeef in ?? () #4 0xdeadbeef in ?? () #5 0xdeadbeef in ?? () #6 0xdeadbeef in ?? () #7 0xdeadbeef in ?? () #8 0xdeadbeef in ?? () #9 0xdeadbeef in ?? () #10 0xdeadbeef in ?? () #11 0xdeadbeef in ?? () #12 0xdeadbeef in ?? () #13 0xdeadbeef in ?? () #14 0x65b9a4d8 in ?? () #15 0x65b9a4d8 in ?? () #16 0x65b9a4d8 in ?? () #17 0x622bc144 in ?? () #18 0x38003412 in ?? () #19 0x00000001 in ?? () #20 0x622bc070 in ?? () #21 0x00000030 in ?? () #22 0xdeadbeef in ?? () #23 0xdeadbeef in ?? () #24 0xdeadbeef in ?? () #25 0xdeadbeef in ?? () #26 0xdeadbeef in ?? () #27 0xdeadbeef in ?? () #28 0xdeadbeef in ?? () #29 0x0000000b in ?? () > How did you run it? valgrind --tool=omega konqueror Thanks, Dirk |
|
From: Bryan M. <bra...@go...> - 2006-10-05 17:49:14
|
Dirk Mueller wrote: > On Wednesday, 4. October 2006 23:46, Bryan Meredith wrote: > >> that's a start - x86 or x86_64? > > x86 > >> What version of gcc do you have on your system? > > gcc 4.1.3 > >> How does it crash? > > it crashes during exit, leaving a big useless core file behind: > > >> How did you run it? > > valgrind --tool=omega konqueror > > > Thanks, > Dirk > Thanks for that Dirk - I am so glad this is on x86. I forgot the other most relevant question - what distro is this on? Bryan |
|
From: Julian S. <js...@ac...> - 2006-10-05 18:06:33
|
> Thanks for that Dirk - I am so glad this is on x86. I forgot the other > most relevant question - what distro is this on? Highly likely to be OpenSUSE 10.2 alpha N where N is the latest available (currently 5). J |
|
From: Dirk M. <dm...@gm...> - 2006-10-05 19:47:15
|
On Thursday, 5. October 2006 20:06, Julian Seward wrote: > Highly likely to be OpenSUSE 10.2 alpha N where N is the latest > available (currently 5). Thats right :) Anyway, it seems the worst problems are caused by the drd patch, removing that one makes omage work (except for the crash on exit I referred to beforehand). Dirk |
|
From: Bryan M. <bra...@go...> - 2006-10-05 19:54:56
|
Dirk Mueller wrote: > On Thursday, 5. October 2006 20:06, Julian Seward wrote: > >> Highly likely to be OpenSUSE 10.2 alpha N where N is the latest >> available (currently 5). > > Thats right :) Anyway, it seems the worst problems are caused by the drd > patch, removing that one makes omage work (except for the crash on exit I > referred to beforehand). > > > Dirk > thanks again Dirk (and Julian). Not sure when I can investigate this - I don't have a machine I can re-install yet (waiting for pptp to get fixed on Suse 10.1 or l2tp support to appear). I will spend some time with x86_64 - it could be a common problem that manifests differently on the differing architectures. Sometimes, I really wish I knew x86 assembler :( Bryan |
|
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: 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: Bryan M. <bra...@go...> - 2006-10-05 23:17:24
|
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 > |