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:29 UTC
[jira] Created: (XERCESC-1599) DTD grammar caching of failed
grammer causes segmentation fault
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
[jira] Updated: (XERCESC-1599) DTD grammar caching of failed
grammer causes segmentation fault
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boris Kolpackov updated XERCESC-1599:
-------------------------------------
Affects Version/s: (was: 2.7.0)
3.0.1
I tried the attached test with 3.0.1. IGXMLScanner works without any problem, including under valgrind. DGXMLScanner on the other hand does cause some memory access/free errors. So it seems this has been fixed in the former but not the latter.
> DTD grammar caching of failed grammer causes segmentation fault
> ---------------------------------------------------------------
>
> Key: XERCESC-1599
> URL: https://issues.apache.org/jira/browse/XERCESC-1599
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (DTD)
> Affects Versions: 3.0.1
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1599) DTD grammar caching of failed
grammer causes segmentation fault
Posted by "Michael Fuller (JIRA)" <xe...@xml.apache.org>.
[ 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