I wrote the "algorithm from hell". Its described in a book affectionately
known as "The Dragon Book", "Compilers: Principles, Techniques, and Tools".
This may not help you, since it still took me quite a while to write that
algorithm, which differs slightly from what would be used by a compiler,
from the descriptions in the book. But if you want a high level explanation
of what its doing, then that's where to look.
--------------------------
Dean Roddey
The Charmed Quark Controller
Charmed Quark Software
[EMAIL PROTECTED]
http://www.charmedquark.com
"If it don't have a control port, don't buy it!"
----- Original Message -----
From: "Brodeur, Stephen (CT)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 12:53 PM
Subject: Bug fixes for Validating Parser (Schema)...
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
