On 12 August 2010 10:08, Noel O'Boyle <baoille...@gmail.com> wrote: > On 11 August 2010 22:53, Chris Morley <c.mor...@gaseq.co.uk> wrote: >> On 11/08/2010 17:47, Konstantin Tokarev wrote: >>> >>> >>> 11.08.10, 20:37, "Noel O'Boyle"<baoille...@gmail.com>: >>> >>>> Hi all, >>>> >>>> I am trying to track down a segfault on a SMI to CML conversion which >>>> fails in the destructor of ~OBConversion at "delete pLineEndBuf". >>>> >>>> I am wondering whether this is related to the following in the copy >>>> constructor OBConversion::OBConversion(const OBConversion& o): >>>> >>>> pLineEndBuf = o.pLineEndBuf; >>>> >>>> "p" indicates a pointer and I think that (in this case) it's either >>>> NULL or else pointing to an object allocated with "new". >>> >>> It's not a good thing that two objects own one data pointer if it's not >>> clear which of them should free memory. >>> Maybe you need to use >>> >>> *pLineEndBuf = *o.pLineEndBuf; >>> >>> (copy instead of share)? >> >> This bug has been, well, bugging me for some time, but I have not been >> able to find why it is happening and have been living with the memory >> leak. The normal way to protect against double deleting is to set the >> pointer to NULL after deleting, but it does not help here. The problem >> seems to be that the source pointer inside the pLineEndBuf's object is >> feeefeee, meaning it has already been deleted (in the Visual Studio >> debugger). >> >> Adding other pLineEndBuf=NULL; in other places also does not help. >> I'm wondering about deletion being in a different DLL from the newing... > > Well, making the change I've suggested gets rid of my segfault on > Windows. This was bugging me because this test was failing on about > half of the platforms, and when I tried to track it down, my debug > builds wouldn't fail. It must be dependent on the order in which > destructors are called. I'm going to check it in, and see if it breaks > any of the tests tonight.
Um...I've spoken too soon. I'll keep working on this for a while and see if anything pops up. - Noel ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
