On Sun, Oct 31, 2004 at 05:21:29PM -0800, [EMAIL PROTECTED] wrote: > > Afaik, when overloading 'placement' new and delete > > like that, the only time the corresponding overload > > of delete will be called is if the constructor throws. > > All other times you have to call the destructor and > > the right version of delete yourself. > > This is not true. If a class implements operator new and delete, they are > called to allocate and deallocate memory. Don't forget you can overload > "placement" new (a term which itself is "overloaded") with arbitrary > parameters, and this is what Xerces-C does.
Ah, I hadn't seen that the KVStringPair inherited an operator delete from XMemory, that explains it all, thanks. > Take a look at the file XMemory.hpp and note the various overloads for > operator new. You will see there is one that takes a size_t and a pointer > to a MemoryManager instance. This is the one that's called when doing > "placement" new with a pointer to a MemoryManager instance. > > This overload of operator delete is the one that's called if the > constructor throws: > > void operator delete(void* p, MemoryManager* memMgr); > > This is the one that's called by the delete expression, and is the one > that retrieves the pointer the MemoryManager instance, and frees the > allocated memory: > > void operator delete(void* p, MemoryManager* memMgr); Presumably you mean void operator delete(void* p) here, but yes this makes sense. > The implementation of these functions in XMemory.cpp will clarify what is > happening. > > > > Often, when I see a crash in freeing memory, I discover that the crash > > > is a symptom of a previous bad transaction with the heap, like > > > deleting a pointer that's already been deleted. > > > > True, but in this case Purify isn't showing anything suspicious. > > Can you should set some breakpoints and make note of the address that's > returned from MemoryManagerImpl::allocate() for this object, and verify > the same address is passed to MemoryManagerImpl::deallocate()? > > You might also want to try a small test program that creates an instance > of IGXMLScanner, then deletes it, to verify something is completely broken > with the code. I used Xerces-C 2.3 extensively, and never had this > problem, but perhaps you have a corrupted library, or you're using a > different compiler and there's a bug. I will do some more investigation and get back to the list if I turn up anything useful. On a slightly different note, I was wondering what the use case for the pluggable memory manager structure is? From my cursory look at it, it seems to add some non-trivial time and space overhead to the usual use of the library where one doesn't care about plugging in a custom memory manager. Thanks very much for your help, Graham. -- Graham Bennett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
