United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6573268 : Four JCK-devtools-6a tests report OOM: Java Heap space since JDK7 b14

Details
Type:
Bug
Submit Date:
2007-06-25
Status:
Closed
Updated Date:
2012-04-24
Project Name:
JDK
Resolved Date:
2007-10-22
Component:
xml
OS:
generic,solaris_10
Sub-Component:
org.xml.sax
CPU:
x86,generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
6u3,7
Fixed Versions:
1.4.0 (1.4)

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

Sub Tasks

Description
JCK            : JCK-DEVTOOLS-6a b14
J2SE           : FAIL - jdk 7 b14, PASS jdk6u2 b05 JDK 7 b13
Platform[s]    : FAIL - seems to be all
switch/Mode    : FAIL - default

Four JCK 6a test fails with OOM (and pass against previous build):

xml_schema/msData/modelGroups/jaxb/mgG014.html#mgG014.v
xml_schema/msData/modelGroups/jaxb/mgJ014.html#mgJ014.v
xml_schema/msData/particles/jaxb/particlesIe003.html#particlesIe003.v
xml_schema/msData/particles/jaxb/particlesR005.html#particlesR005.v

                                    

Comments
EVALUATION

Fixed. The Feature for Secure Processing for SchemaFactory is now true by default.
                                     
2007-10-22
EVALUATION

While XML Schema tests for JAXP report expected error message, corresponding JAXB tests with the same schemata fail with OOME or hang. Since this CR was initially created against JAXB tests, it cannot be considered fixed.

JAXP tests fail with message like"Fatal Error: Current configuration of the parser doesn't allow a maxOccurs attribute value to be set greater than the value 5,000.":
xml_schema/msData/modelGroups/jaxp/mgG014.html#mgG014.v
xml_schema/msData/modelGroups/jaxp/mgJ014.html#mgJ014.v
xml_schema/msData/particles/jaxp/particlesIe003.html#particlesIe003.v
xml_schema/msData/particles/jaxp/particlesR005.html#particlesR005.v
These tests are run using SAXParserFactory.

JAXB tests fail with either OOME:
xml_schema/msData/modelGroups/jaxb/mgG014.html#mgG014.v
xml_schema/msData/modelGroups/jaxb/mgJ014.html#mgJ014.v
xml_schema/msData/particles/jaxb/particlesIe003.html#particlesIe003.v
JAXB tests hang:
xml_schema/msData/particles/jaxb/particlesR005.html#particlesR005
xml_schema/msData/particles/jaxb/particlesR005.html#particlesR005.v

It seems like the reason of these failures is that FEATURE_SECURE_PROCESSING is false by default in javax.xml.validation.ValidatorHandler. This handler is used in JAXB [1].
I think the fix for these failures (OutOfMemoryError is thrown) is to either:
1. Make FSP == true by default. This will require a CCC request.
2. To work further on fixing of this bug in JAXP in some other way.

[1] https://jaxb2-sources.dev.java.net/source/browse/jaxb2-sources/jaxb-ri/runtime/src/com/sun/xml/bind/v2/runtime/unmarshaller/ValidatingUnmarshaller.java?rev=1.9.2.1&view=markup
                                     
2007-07-31
EVALUATION

The fix is now available on java.net through the lastest build in the download section. Fatal errors now reported for the above JCK tests in situations that led to OOM previously. Please refer to the JAXP compatibility guide, section "Feature for Secure Processing", and note that the feature is turned on by default when using the SAX or DOM factory, but not for the SchemaFactory. 

This fix will be considered in future JDK 6 update releases.
                                     
2007-07-30
EVALUATION

This "apparent" regression is due to a patch available in the latest JAXP RI and in JDK 7 which isn't in 6u2. This is the original bug report,

https://jaxp.dev.java.net/issues/show_bug.cgi?id=30

In summary, the original optimization introduced in JDK 6 to avoid linear-space algorithm was a bit aggressive, and resulted in false positives in a few cases. Thus, this optimization had to be adjust to handle a more restricted set of cases. Hence, the difference in behavior between 6u3 and the latest JDK 7 build (which is in synch with the latest JAXP RI). In fact, it the test in this report should behave just like in JDK 5. If the maxOccurs is used on the xs:element rather than xs:sequence, then the optimization should kick in, thus showing the difference between JDK 5 and JDK 7.
                                     
2007-06-25



Hardware and Software, Engineered to Work Together