[ http://issues.apache.org/jira/browse/XERCESC-1334?page=comments#action_58520 ] Alberto Massari commented on XERCESC-1334: ------------------------------------------
As far as I remember, calling "delete aTranscoder" will invoke XMemory::delete, that will look in the 4 bytes preceding the allocated memory to find out which memory manager was used to allocate the object, and tell him to deallocate it. Can you follow the code in the debugger to check that you see this behavior? Alberto > XMLTransService::makeNewTranscoderFor(...) does not have a corresponding > method to release the memory it allocates. Once a new XMLTranscoder is > created, no other feasible way to clear up the memory except for calling > XMLTranscoder destructor explicitly > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: XERCESC-1334 > URL: http://issues.apache.org/jira/browse/XERCESC-1334 > Project: Xerces-C++ > Type: Improvement > Components: Utilities > Versions: 1.5, 1.5.1, 1.5.2, 1.6.0 > Environment: WinXP/VC7.1 > Reporter: xuerong tang > Priority: Critical > > a)Problem description: > Once TransService is used to create a new XMLTranscoder, no other feasible > way to clear up the memory except for calling XMLTranscoder destructor > explicitly. The signature of the creation function is as follows: > XMLTranscoder* XMLTransService::makeNewTranscoderFor > b)Analyzed the problem: > i.The class tree is XMemory --> XMLTranscoder --> XMLUTF8Transcoder. The > delete/new operators in the base class were overloaded with pluggable memory > manager (default is Xerces’ MemoryManager class implementation, which > currently uses global operators ::operator delete, ::operator new in a > straightforward manner). The function signature is like this: > void* XMemory::operator new(size_t size, MemoryManager* manager) > void XMemory::operator delete(void* p, MemoryManager* manager) > ii.Although the definitions for the above new/delete appeared symmetric, they > are actually not. In C++, there is a way of calling this overloaded new > operator using “replacement new” syntax: e.g., new (manager) > XMLTranscoder(…), which will call the overloaded new operator (do some memory > allocation in this case) first and then call the class constructor (do some > further memory allocation in this case). Unfortunately, there is no such a > “replacement delete” that will “undo” these things automatically. As a > result, whenever “placement new” was used, for releasing the memory, the > destructor should be called explicitly first, then the overloaded delete > should be called (so that the corresponding memory manager is used) to free > up the memory. See BJARNE’s C++ Programming Language (3rd Edition) Page 256 > for detailed explanation. > iii.Debugging into method makeNewTranscoderFor(…) reveals that it called > “replacement new” to do the memory allocation: > template <class TType> XMLTranscoder* > ENameMapFor<TType>::makeNew(const unsigned int blockSize, > MemoryManager* const manager) const > { > return new (manager) TType(getKey(), blockSize, manager); > } > but it seemed to me that Xerces did not provide a corresponding method to > release&clean up objects (at lease in current releases 2.5.0 and 2.6.0) > iv.Without a corresponding destroyTranscoder(...) to hide the detail of > releasing the memory for me, I have to use the following “messy” code: > //create a new transcoder > XMLTranscoder* aTranscoder = XMLPlatformUtils::fgTransService-> > makeNewTranscoderFor(encodingName, resCode, 16*maxBufferSize, > XMLPlatformUtils::fgMemoryManager); > //do some work with the transcoder > ... > //messy code for releasing all the memory > aTranscoder->~XMLTranscoder(); //release the memory allocated in constructor > aTranscoder->operator delete(aTranscoder, XMLPlatformUtils::fgMemoryManager); > //release the memory allocated by replacment new > c) Proposed improvement > XMLTransService should provide a corresponding DestroyTranscoder(...) method > that will internally call the above two lines of code so that the > implementation detail is hidden to the Xerces users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
