On 11/06/2010 09:34, Noel O'Boyle wrote: > 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.
The commandline is slightly different. It needs -O before the output file name. (It was originally written because you got confused with the input format and managed to delete an input file.) So an automatic replacement isn't on. You can't herd cats just by calling them sheep. > >> 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. > Craig is using it in a server, where I'm surprised that the memory leaks don't show up. >>>> 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
