On 11 August 2010 22:53, Chris Morley <[email protected]> wrote: > On 11/08/2010 17:47, Konstantin Tokarev wrote: >> >> >> 11.08.10, 20:37, "Noel O'Boyle"<[email protected]>: >> >>> 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).
I've tracked this part down, I think. The XML OBConversion is a copy of the original OBConversion but they share the same pInStream (which is the source in pLineEndBuf). The XML OBConversion gets called first, and deletes the pInStream as part of deleting the source in "delete pLineEndBuf". (Where is the destructor for pLineEndBuf? Is it in the base class?) Then the original OBConversion gets destroyed. It tries to delete the source again as part of "delete pLineEndBuf" but it has already been deleted. If we had access to the destructor we could fix this. - Noel > Adding other pLineEndBuf=NULL; in other places also does not help. > I'm wondering about deletion being in a different DLL from the newing... > > Chris > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/openbabel-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/openbabel-devel
