On 10 June 2010 23:07, Chris Morley <c.mor...@gaseq.co.uk> wrote: > On 10/06/2010 22:32, Tim Vandermeersch wrote: >> On Thu, Jun 10, 2010 at 10:33 PM, Noel O'Boyle<baoille...@gmail.com> wrote: >>> On 10 June 2010 21:27, Tim Vandermeersch<tim.vandermeer...@gmail.com> >>> wrote: >>>> On Thu, Jun 10, 2010 at 10:22 PM, Noel O'Boyle<baoille...@gmail.com> >>>> wrote: >>>>> Hi all, >>>>> >>>>> The built-in memory leak detection in MSVC2008 seems not to work (no >>>>> line numbers), but I've found Visual Leak Detector to work amazingly >>>>> well (given that I don't know what I'm doing): >>>>> http://sites.google.com/site/dmoulding/vld >>>>> >>>>> Basically, I installed that and followed the simple instructions, and >>>>> then added "include<vld.h>" to the top of obconversion.h, and then >>>>> ran "babel" in Debug mode with an SDF to SDF conversion. >>>>> >>>>> Converting 5 files, there are 80 memory leaks. Then I found that one >>>>> of the memory leaks was one of my first contributions to OpenBabel: >>>>> _frag_atoms = new OBBitVec(_pmol->NumAtoms());. By adding a delete to >>>>> the destructor I got down to 70 leaks. >>>>> >>>>> If anyone's interested in the log file I can provide it. >>>> >>>> Yes, I'd like to have a look. When I run in valgrind, I always detect >>>> a few leaks when reading molecules. I don't know where they are coming >>>> from but perhaps another tool might contain other information. Just >>>> like some bugs, these detected leaks can be platform specific. >>> >>> Actually, it seems that all of the other leaks (I think) are >>> associated with RegisterOptionParams. Maybe you could take a look. >> >> Could you try the attached patch? >> > I never found the Visual Studio leak detection very satisfactory > either. Most of the leaks I came across were of the sort in > RegisterOptionParams where they are allocated only once and so are are > not very serious. (This is not quite true if new instances of formats > are used, which is currently rare.) Using a static local variable as > Tim suggests is better and most of the similar cases are done that way.
I forgot to check whether the number of leaks increased with converting additional molecules. If not, then as you say, it's not really that serious. I'll check Tim's patch. > If we could persuade people to use obabel rather than babel, we could > get rid of RegisterOptionParams entirely! Hooray! Can we replace babel with a file that just calls obabel? I'm serious. That would fulfill our background compatability obligations and smooth the transition. > I found more serious leaks in the 2D coordinate generation code (for > --gen2D) but curing them I think involves significant code changes and > isn't done yet. We can call this "experimental" code, and output a HERE BE DRAGONS warning. >>> See http://pastebin.com/q60k28nZ (unfortunately, due to the #include >>> in obconversion, the line numbers will be one or two off). >>> > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > OpenBabel-Devel mailing list > OpenBabel-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbabel-devel > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
