Almost all of these are all known and they are designed to work that way.
We cannot take the approach you suggested below, which is to use global or
static objects that will clean themselves up. This is a long and ongoing
discussion which has been had a number of times. There is no guarantee of
the order of global object construction and destruction in C++. Therefore,
global objects are very bad things and are to be avoided at all costs
because they can cause really bad errors that almost impossible to figure
out.
Therefore, the parser is designed to lazily create such objects. They are
intended to live for the life of the process and will naturally go away
when the process ends. If you want to use them within a COM object, you
will have to take some step to insure that the same copy of the parser DLL
stays loaded.
We may, in a future release, provide a cleanup method that you can
explicitly call. But, even that would be problematic because the way that
many lazy eval schemes work, its difficult for any outsider to easily get
to the data. So it might take a good bit of work to provide such a
function.
A couple of the things you report look like they could be legitmate leak
type bugs and we will look at those.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Solinski, Mark" <[EMAIL PROTECTED]> on 02/22/2000 01:23:20 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: XML4C++ 1.1.0 memory leaks
I have found a few memory leaks in the XML4C++ 1.1.0 DLL. We are building
COM components under
Win32 which parse XML files. Since these COM components are loaded and
unloaded multiple times in the same process address space, minor memory
leaks tend to accumulate. To find these, I built a DLL with one exported
function, void fnTestXML(). I then created a test harness executable which
dynamically loads the DLL, with LoadLibrary, calls fnTextXML (loaded
address
retrieved from GetProcAddress), and then unloads the DLL. I've written
fnTestXML to have the code body of the various sample applications -
DOMPrint, SAXPrint, CreateDOMDocument and Pparse and used CompuWare's
BoundsChecker to test for memory leaks. This is what I found:
DStringPool.cpp: DStringPool::getStaticString does a "new DOMString(in)"
which is called from many locations but the string is never deleted.
DOMString.cpp: DOMString::getMutex does a "new XMLMutex" which is never
deleted.
DOMString.cpp: DOMStringHandle::operator new does a "new
DOMStringHandle[allocGroupSize]" which is never deleted AND if it is called
more than allocGroupSize times (creating more than allocGroupSize
DOMStrings), the first "new" is dereferenced as a "new
DOMStringHandle[allocGroupSize]" is called.
XMLScanner.cpp: gScannerMutex() does a "new XMLMutex" that is never
deleted.
*
Mutexes.cpp: The destructor ~XMLMutex after calling closeMutex should
delete fHandle.
PlatformUtils.cpp: XMLPlatformUtils::fgNetAccessor and
XMLPlatformUtils::fgTransService are never deleted.
PlatformUtils.cpp: XMLPlatformUtils::Initialize does a "new XMLMutex" that
is never deleted.
XMLException.cpp: gMsgMutex() does a "new XMLMutex" that is never deleted.
TransService.cpp: XMLTransService::initTransService() does a "new
RefHashTableOf<ENameMap>(103)" that is never deleted. This can be fixed
easily by replacing...
gMappings = new RefHashTableOf<ENameMap>(103);
...with...
static RefHashTableOf<ENameMap> mappings(103);
gMappings = &mappings;
Win32PlatformUtils.cpp: XMLPlatformUtils::loadMsgSet returns "new
Win32MsgLoader(msgDomain)" that is never deleted.
I hope this helps. If you need further information send me a note.
Mark Solinski
SAP Campbell
