[jira] Issue Comment Edited: (XERCESC-1051) Crash when maxOccurs >= 200000

["Karsten Strunk (JIRA)" <xe...@xml.apache.org>]

    [ 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org