Greetings,
I've discovered some memory leaks in the Validating Parser package, and have
implemented some fixes. There are some remaining leaks, but the torrential leak is
now a trickle. Bugzilla is down, so I'll simply submit this fix. If you find that
this fix is valid, as I believe it is, I'd love my name on the contributor's list.
It'd really "spin my propeller"...
Xerces C++ Version Number: 1.5.1
Platform: Win32
OS: Windows 2000 Version 5.0 (build 2195: Service pack 2)
XML document that failed: No failure -- just memory leaks. Any reasonably complex
schema with user-defined data types will do.
C++ Application Code that failed:
xerces-c-src1_5_1\src\validators\common\DFAContentModel.cpp
xerces-c-src1_5_1\src\validators\datatype\DecimalDatatypeValidator.cpp
xerces-c-src1_5_1\src\validators\schema\TraverseSchema.cpp
Fixes are attached. Overview for each fix:
validators\common\DFAContentModel.cpp :
The majority of the fix lies in DFAContentModel::buildDFA(), which contains
the "algorithm from hell". I don't pretend to thoroughly understand the algorithm
(yet), but the problem lies in the release of nodes within the syntax tree. The
fLeafList attribute contained references to the leaves of the syntax tree, and was
used for resource release. This left intermediate nodes leaking into the bit bucket.
The "fix" is to delete the root node and merely delete the fLeafList attribute.
There's still a potential leak for allocations that occur in the postTreeBuildInit()
method, but the fix requires deeper understandingn of the "algorithm from hell". For
our use, this is a complete fix, since these types of allocation do not occur for our
files.
Other, easier fixes included the stack allocation of QName objects fed to
CMLeaf ctors, since a copy is made in the ctor.
validators\datatype\DecimalDatatypeValidator.cpp :
The init() routine was leaking XMLCh* strings when checking min/max
inclusive/exclusive values. Fixed -- ArrayJanitor to the rescue.
validators\schema\TraverseSchema.cpp :
This may be debatable as whether it's a "fix", but for our application, we've
got over a dozen separate XML configuration files, and we can be "reconfigured"
dynamically, causing a reparse of the files. The lazy initialization of the
XMLStringPool attribute caused accumulated leaks, so I merely changed it to a dynamic
allocation within doTraverseSchema(). Since it's purely implementation, very safe.
I've already attempted to send you the above files as attachments, and was
rejected to to oversized e-mail filtering. I've got the fixes ready for your
inspection -- let me know the process...
Regards,
Steve Brodeur
[EMAIL PROTECTED]
alternate e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
