xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Bennett <graham-xer...@simulcra.org>
Subject Re: possible memory bug
Date Mon, 01 Nov 2004 21:40:47 GMT
On Sun, Oct 31, 2004 at 05:21:29PM -0800, david_n_bertoni@us.ibm.com 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

Thanks very much for your help,


Graham Bennett

To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

View raw message