[
https://issues.apache.org/jira/browse/XERCESC-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502384
]
Karsten Strunk edited comment on XERCESC-1051 at 6/7/07 8:27 AM:
-----------------------------------------------------------------
I think, I'm encountering a similar problem with Xerces 2.7.0. Xerces crashes
when maxOccurs is too large.
Xerces always allocates memory for elements according to the number specified
in maxOccurs, regardless of the real number of elements in xml instance. If the
real numer of elements is small, most allocated elements are not needed.
For example:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:element name="computer">
<xs:complexType>
<xs:sequence>
<xs:element name="serialNumber" maxOccurs="10000"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<computer>
<serialNumber>1</serialNumber>
</computer>
In this case 10000 elements are created, but only 1 is really needed. I found
the following code fragment in ComplexTypeInfo::expandContentModel:
for (int j=1; j < maxOccurs-minOccurs; j++) {
retNode = new (fMemoryManager) ContentSpecNode
(
ContentSpecNode::Sequence
, retNode
, optional
, true
, false
, fMemoryManager
);
}
In my case I have a xml schema which uses maxOccurs="9999999". So each time
this element is found in a xml instance 9999999 elements are created although
normally just a few are really needed. So I'd also prefer a counting version
which creates only the really needed elements.
was:
I think, I'm encountering a similar problem with Xerces 2.7.0. Xerces crashes
when maxOccurs is too large.
Xerces always allocates memory for elements according to the number specified
in maxOccurs, regardless of the real number of elements in xml instance. If the
real numer of elements is small, most allocated elements are not needed.
For example:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:element name="computer">
<xs:complexType>
<xs:sequence>
<xs:element name="serialNumber" maxOccurs="10000"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<computer>
<serialNumber>1</serialNumber>
</computer>
In this case 10000 elements are created, but only 1 is really needed. I found
the following code fragment in ComplexTypeInfo::expandContentModel:
for (int j=1; j < maxOccurs-minOccurs; j++) {
retNode = new (fMemoryManager) ContentSpecNode
(
ContentSpecNode::Sequence
, retNode
, optional
, true
, false
, fMemoryManager
);
}
In my case I have a xml schema which uses maxOccurs="9999999". So each time
this element is found in a xml instance 9999999 elements are created although
normally just a few are really needed. So I'd also prefer a counting version
which created only the really needed elements.
> Crash when maxOccurs >= 200000
> ------------------------------
>
> Key: XERCESC-1051
> URL: https://issues.apache.org/jira/browse/XERCESC-1051
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Affects Versions: 2.3.0
> Environment: Operating System: Windows NT/2K
> Platform: PC
> Reporter: Frank Rast
> Assignee: Alberto Massari
>
> Parser crashes in ContentSpecNode.hpp: ContentSpecNode::~ContentSpecNode().
> Steps to reproduce:
> validate a xml file against a schema with an element having a maxOccurs >=
> 200000.
> Assumed cause:
> Stack overfow
> Makeshift resolution:
> Set the repeat count to unbounded(-1), when maxOccurs > 500:
> inline void ContentSpecNode::setMaxOccurs(int max)
> {
> if(max > 500)
> max = -1;
> fMaxOccurs = max;
> }
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
