DTD grammar caching of failed grammer causes segmentation fault
---------------------------------------------------------------
Key: XERCESC-1599
URL: http://issues.apache.org/jira/browse/XERCESC-1599
Project: Xerces-C++
Type: Bug
Components: Validating Parser (DTD)
Versions: 2.7.0
Environment: All.
Reporter: Michael Fuller
Priority: Critical
Attachments: test-12907.tar
Problem:
If you enable grammar caching and:
* DTD validate a valid document
* DTD validate an invalid document
* DTD validate an valid document
a segmentation fault, etc. occurs inside Xerces.
Apparent cause:
When parsing a document in DTD mode, the parser always creates a temporary
grammar called "[dtd]". If the parser successully parses the document,
it puts the parsed DTD in "[dtd]" and then renames "[dtd]" to the real
name of the DTD.
However, if the parse does not succeed, the parser (erroneously?)
just leaves "[dtd]" in the grammer cache. This means that "[dtd]"
exists in the grammar cache when a new document is parsed later that
uses a novel DTD, then the presence of "[dtd]" in the grammar cache
will eventually cause a memory leak and double free, ultimately
causing a crash (see attached dbx or gdb output).
This affects users of the DGXMLScanner and the IGXMLScanner.
A fix for the problem is to make sure that before "[dtd]" is placed
in the grammar cache any existing "[dtd]" is removed.
The attached test case failed under both Solaris and Linux.
Under Solaris, depending on where the files were located, environment, etc.
it would sometimes crash, and sometimes not. However, even when it did not
crash, it was still double freeing, etc; this can be seen by running
"bcheck test-12907" (output attached).
Under linux, it always seems to crash with:
*** glibc detected *** free(): invalid pointer: 0x000000000050ed18 ***
However, even if the erroneous code does not trigger a crash,
valgrind should show the problem.
We have developed a kludgy workaround, but I do not think
that it is a "good" fix. See the attached diffs against 2.7.0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
