JDK-6573268 : Four JCK-devtools-6a tests report OOM: Java Heap space since JDK7 b14
  • Type: Bug
  • Component: xml
  • Sub-Component: org.xml.sax
  • Affected Version: 6u3,7
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2007-06-25
  • Updated: 2017-05-16
  • Resolved: 2007-10-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7 Other
1.4.0,OpenJDK6Fixed 6u10Fixed 7Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-6449928 - For api/xml_schema/msxsdtest throw OOM due to too big values of maxOccurs or minOccurs
Relates :  
JDK-6738894 - Merge jaxp fixes from 6 update train into OpenJDK 6 and 7
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.
22-10-2007
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
31-07-2007
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.
30-07-2007
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.
25-06-2007