You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Michael Fuller (JIRA)" <xe...@xml.apache.org> on 2006/05/30 08:48:30 UTC
[jira] Updated: (XERCESC-1599) DTD grammar caching of failed
grammer causes segmentation fault
[ http://issues.apache.org/jira/browse/XERCESC-1599?page=all ]
Michael Fuller updated XERCESC-1599:
------------------------------------
Attachment: test-12907.tar
> 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org