In the most recent code in the CVS repository there is a termination
method. It cleans up all the code that the platform utils class allocated
itself, and it provides a registration mechanism via which higher level
code can register lazily evaluated objects to be cleaned up. We have not
yet though gone through all the code and made use of this registration
mechanism, though we should by the time the next release comes out.
We cannot use any proactive initialization mechanism because that is not
portable, so we will continue to do the lazy evaluation route. But the
termination call, and the ability to register data to be cleaned up, should
solve the problems for those folks who need to load and unload the DLL.
The new termination call is not required. If you don't call it, then it
works just like it does today where these lazily evaluated resources are
just released as the process dies. But, if you want to call it, you can,
even if you don't do dynamic load/unload.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
Alex Matevossian <[EMAIL PROTECTED]> on 03/24/2000 11:25:57
AM
Please respond to [EMAIL PROTECTED]
To: Andy Heninger/Cupertino/[EMAIL PROTECTED], "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
cc: Alex Matevossian <[EMAIL PROTECTED]>, Steve Chuang
<[EMAIL PROTECTED]>, Cliff Dibble
<[EMAIL PROTECTED]>, Mike Hatalski
<[EMAIL PROTECTED]>, Mike Miele
<[EMAIL PROTECTED]>, Hatem ElSebaaly
<[EMAIL PROTECTED]>, Robert Asis <[EMAIL PROTECTED]>
Subject: Memory leaks in xerces-c_1_1.dll
Hi Andy,
This is a follow-up to the email sent 2 days ago by Steve Chuang re memory
leaks in Xerces.
Summary
Xerces DLL allocates memory on the heap during initialization. Since the
memory is not cleaned automatically by the DLL and the DLL provides no
mechanism to release the memory explicitly, the memory will be released
only
when the process hosting the DLL terminates.
This creates memory leaks if the DLL is dynamically loaded and unloaded by
the hosting process.
Details
Before using any functionality provided by xerces-c_1_1.dll, one needs to
call void XMLPlatformUtils::Initialize() to initialize the library.
Several
objects are allocated on the heap during this initialization (it is
possible
that other resources are allocated, but we did not conduct a thorough
examination).
To avoid redundant object allocations, the bool
XMLPlatformUtils::fgInitFlag
is used to indicate whether this is the first or subsequent invocation of
XMLPlatformUtils::Initialize().
The approach outlined above works perfectly well if the DLL is loaded no
more than once into the hosting process. If the DLL is loaded more than
once, the XMLPlatformUtils::fgInitFlag is reset every on every load. This
will cause another allocation of the objects on the heap. Since there is
no
way to release the resources allocated on the heap by the DLL, every time
the DLL is loaded and initialized, another set of objects will be allocated
on the heap.
On the other hand, I believe it is fair to say that the implementer of the
DLL cannot assume how the DLL is used (i.e., statically linked or
dynamically loaded, loaded once or many times, etc.). That is why we would
like to ask you to either (1) add automatic cleanup (possibly triggered in
the DllMain() on DLL_PROCESS_DETACH event) or (2) provide an explicit
mechanism for releasing the resources (e.g.,
XMLPlatformUtils::UnInitialize() or something similar in nature). We would
prefer to have both features; however, if you can only implement one of the
features, the explicit control of resources seems more important to us.
I am attaching a zip file containing the VC 6 projects illustrating the
problem. In this project I also create mutexes (named and unnamed) and
file
(just to show that those types of resources leak as well as heap memory; I
don't know whether xerces-c_1_1.dll creates those during initialization or
not).
The project structure is as follows:
XC\
Common.h - file included by all projects. This file controls which
objects are allocated.
client\ - the project that generates the hosting exe
comLib\ - the project that generates an intermediate DLL. This DLL is
dynamically loaded/freed by the client.exe. This DLL is statically linked
to the XercesLib.dll
XercesLib\ - the project that generates XercesLib.dll. This DLL
simulates
xerces-c_1_1.dll.
XercesLib.dsw - the workspace that includes all three projects with the
appropriately set dependencies.
Debug\ - the directory containing the debug builds of all three projects.
Release\ - the directory containing the release builds of all three
projects.
To simplify the testing, XercesLib exports only this:
class XERCESLIB_API XMLPlatformUtils
{
public :
static void Initialize();
private :
static bool fgInitFlag;
};
There are #define's that allow you control the number of times
XercesLib.dll
is loaded/called/unloaded, the size of heap allocations, and whether to
create mutex and files (files are created in "C:\Temp", if you don't have
this directory, you should either create it or modify the path in *.cpp
files).
Thank you in advance for your help.
Regards,
Alex Matevossian.
IPNet Solutions.
<<Xc.zip>>
(See attached file: Xc.zip)
<<attachment: Xc.zip>>
