Hi Paul, It'd be great if you have the time to dive into the code and help clean things up.
If you haven't done so already, you'll want to start working with the current source base from CVS, rather than working with the prepackaged 1.1.0 files. I've attached an earlier mail with some further information on the leaks that are being reported. Cleaning them wont be difficult, they just haven't yet bubbled to the top of our queue here. (They are not really leaks for most ordinary use of Xerces, although they can cause problems if the DLL is repeatedly loaded and unloaded). Mail any patches back to this list, and I'll put the changes back into CVS. -- Andy ----- Original Message ----- From: "Paul Wilkerson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 29, 2000 1:22 PM Subject: Participate > I would like to participate as a Beta tester of Xerces. I am already using > xerces and would like to give feedback. I am developing under windows NT > 4.0, with DevStudio 6 SP3. I am using the SAX API primarily, in conjunction > with MFC. Curently DevStudio is reporting memory leaks. How cam I best help > to fix this problem. > ================================================================== 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] Hi Alex, You are correct. Xerces will leak if the DLL is dynamically loaded, unloaded, and loaded again. As Dean notes in his earlier reply, he has added a termination method and a hook by which this kind of storage can be recovered. An example of use of the new mechanism for registering an object for deletion at termination is in the file src/internal/XMLScanner, at line 197. The application code triggers the termination cleanup by calling XMLPlatformUtils::Terminate() just before unloading the Xerces DLL. As Dean noted, not all of the lazily allocated storage is currently set up to use this mechanism - actually, most of it doesn't yet. We will be getting to this over time, but if you would like to speed things along, I'll be more than happy to put any patches for this back into CVS. Best regards, -- Andy From: "Alex Matevossian" <[EMAIL PROTECTED]> > 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 deleted]
