United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8028111 XML readers share the same entity expansion counter
JDK-8028111 : XML readers share the same entity expansion counter

Details
Type:
Bug
Submit Date:
2013-11-11
Status:
Closed
Updated Date:
2014-01-20
Project Name:
JDK
Resolved Date:
2013-11-27
Component:
xml
OS:
Sub-Component:
jaxp
CPU:
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u55,6u65,7u45,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
Issue described here:
https://forums.oracle.com/thread/2594170
Oct 23, 2013 11:07 PM by Borislav.Andruschuk
 
Description:
 
After upgrading to 1.7.0_45 we have noticed that StAX XMLInputFactory started throwing an exception on reader creation for our simple XML messages. After some investigation, we found that all XML readers share the same XMLSecurityManager and the same XMLLimitAnalyzer with its aggregated total entity expansion counter. It is my understanding that the counter is supposed to be local per reader and not shared across all of them.
 
The default entity expansion limit is 64000 and if XMLInputFactory tries to create more than 64000 readers It fails because XMLLimitanalyzer total counter is accumulated and at some point exceeds the limit.
 
OS version:
 
I assume It should be related to all OS versions, checked only MacOS and RHEL
 
Development Kit or Runtime version:

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
 
Regression information:

Test case defined below works on prior JDK versions to 1.7.0_45

Steps to Reproduce:

1. create XMLInputFactory
 
XMLInputFactory factory = XMLInputFactory.newInstance();
 
2. create XMLEventReader:
 
factory.createXMLEventReader(stream);
 
3. repeat step 2 64001 times (default entity expansion limit is 64000)
 
Expected Result:

XMLInputFactory should be able to create as many XMLReaders as requested
 
Actual Result:

JAXP00010001 error

Error Message(s):
 
Exception in thread "main" javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.setInputSource(XMLStreamReaderImpl.java:219)
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.<init>(XMLStreamReaderImpl.java:189)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.getXMLStreamReaderImpl(XMLInputFactoryImpl.java:277)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:129)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLEventReader(XMLInputFactoryImpl.java:78)
at Main.main(Main.java:38)
 
Source code for an executable test case:

import java.io.ByteArrayInputStream;
 
import javax.xml.stream.XMLInputFactory;
 
public class Main {
 
    public static void main(String[] args) throws Exception {
 
        String xml = "<?xml version=\"1.0\"?><test></test>";
 
        XMLInputFactory factory = XMLInputFactory.newInstance();
 
        for (int i = 0; i < 64001; i++) {
 
            ByteArrayInputStream stream = new ByteArrayInputStream(xml.getBytes());
            factory.createXMLEventReader(stream);
        }
    }
}
 
Workaround:
 
The workaround is to disable FPS or entity expansion limit (be careful now your code can be vulnerable to denial of service attack, see replies on Bug ID: JDK-4843787 org.xml.sax.SAXException was thrown when parsing large file )
 
- set system property jdk.xml.entityExpansionLimit to 0
- disable FPS in XMLSecurityManager for XMLInputFactory:
 
        XMLInputFactory factory = XMLInputFactory.newInstance();
        XMLSecurityManager securityManager = new XMLSecurityManager(false);
        factory.setProperty("http://apache.org/xml/properties/security-manager", securityManager);
                                    

Comments
The limit values need to be reset per each parsing operation.
                                     
2013-11-11
Related below 3 tests work well based on latest 8-cpu1401 binaries.

javax/xml/jaxp/common/8014530/ResetLimitTest.java
javax/xml/jaxp/common/8014530/ResetLimitXSLTTest.java
javax/xml/jaxp/common/8014530/StAXLimitTest.java
                                     
2014-01-08
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/932684ede1c6
User:  lana
Date:  2014-01-17 01:17:29 +0000

                                     
2014-01-17
Wordaround:

The workaround is to increase the entity expansion limit, and total entity size limit depending on the size of the entity references.  The getEntityCountInfo Property may be helpful in evaluating the limits. Please refer to http://docs.oracle.com/javase/tutorial/jaxp/limits/using.html for more details.
                                     
2013-11-11
Workaround:

Assuming it's feasible to re-create the factory, then a better workaround is to refresh the factory upon encountering the JAXP00010001 EntityExpansionLimit error. Using the code as in the bug report, the following demonstrate this approach:

    static XMLInputFactory factory = XMLInputFactory.newInstance();
    
    public void workaround() {
        String xml = "<?xml version=\"1.0\"?><test></test>";
        try {
            int reTry = 0;
            for (int i = 0; i < 64001; i++) {

                ByteArrayInputStream stream = new ByteArrayInputStream(xml.getBytes());
                try {
                    factory.createXMLEventReader(stream);
                } catch (XMLStreamException e) {
                    if (reTry == i) {
                        ///this individual file does exceed the limit
                        throw new XMLStreamException(e);
                    }
             
                    //refresh the factory
                    if (e.getMessage().indexOf("JAXP00010001") > -1) {
                        factory = XMLInputFactory.newInstance();
                        reTry = i;
                        i = i-1;
                    }
                }
                
            }
        } catch (Exception e) {
            //handling exception
        }

    }
                                     
2013-11-16
CAP member had reported the same regression bug in Java 7u45/6u65 . This bug killed their production system after a short period of time and they had to roll back to the previous versions.
The details are already public, for example: https://forums.oracle.com/thread/2594170

It is a critical issue for the CAP member and would like have a fix for 6 and 7 update releases
                                     
2013-11-18
SQE OK to take the fix into CPU14_01 based on the nighlty test run results.
                                     
2013-12-01
Just to note another example of this in OpenGamma:
http://jira.opengamma.com/browse/PLAT-5046
We're going to recreate the factory every time as the fix.

                                     
2013-12-02



Hardware and Software, Engineered to Work Together