Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
CurrentCVS, 1.9
-
None
-
MSVC6 / Win2k
Description
I think there is a problem when cleaning-up InputSources returned by a call to resolveEntity() on an EntityResolver.
The problem lies in routine XSLTEngineImpl::parseXML(), at line 652 of file XSLTEngineImpl.cpp:
A smart pointer of kind XalanMemMgrAutoPtr is used to manage the pointer to the InputSource obtained from the EntityResolver.
However, Xerces' class InputSource inherits from XMemory, and this causes trouble when the XalanMemMgrAutoPtr tries to free the memory.
Indeed, XMemory has customized new() and delete() operators that,
in addition to the space required to hold the object,
also allocates a little space for a special "header" placed just before.
The pointer returned by new() points just after the header, not at the beginning of the allocated area.
In turn, XalanMemMgrAutoPtr calls the memory manager to deallocate the InputSource,
but is not aware of the special header of XMemory objects, and so pass the wrong address to delete()...
On my Windows machine, this systematically results in a bad memory access exception.
I think this problem could also be the cause of the memory leak observed by someone else on this list
(see thread "Changes, bugs, etc. between 1.8 and 1.9").
I guess some system allocators are just stricter than others when delete() is given the wrong address.
I am not too sure how to best fix this problem.
I just replace the use of XalanMemMgrAutoPtr by a simple XalanAutoPtr at line 652, and I don't have any problem anymore.
Maybe it could also be possible to define a template specialization for XalanMemMgrAutoPtr for type XMemory to account for the "header"?
Best regards,
Alain Le Guennec.