Bug #3665
closedArrayIndexOutOfBounds in PrecedingSiblingIterator during schema validation
100%
Description
Crash in 9.8 during XML validation:
java.lang.ArrayIndexOutOfBoundsException: 1617
at net.sf.saxon.tree.tiny.PrecedingSiblingIterator.next(PrecedingSibling
Iterator.java:47)
at net.sf.saxon.tree.wrapper.VirtualCopy$VirtualCopier.next(VirtualCopy.
java:757)
at net.sf.saxon.tree.util.Navigator.getNumberSimple(Navigator.java:327)
at net.sf.saxon.tree.util.Navigator.getPath(Navigator.java:217)
at net.sf.saxon.tree.util.Navigator.getPath(Navigator.java:212)
at net.sf.saxon.tree.util.Navigator.getPath(Navigator.java:184)
at com.saxonica.ee.validate.InvalidityReportGeneratorEE.reportInvalidity
(InvalidityReportGeneratorEE.java:191)
at com.saxonica.ee.validate.ValidatingFilter.reportValidationError(Valid
atingFilter.java:180)
at com.saxonica.ee.validate.ValidationStack.testAssertions(ValidationSta
ck.java:508)
at com.saxonica.ee.validate.ValidationStack.endElement(ValidationStack.j
ava:430)
at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:182)
at net.sf.saxon.event.StartTagBuffer.endElement(StartTagBuffer.java:290)
at com.saxonica.ee.validate.StartTagBufferEE.endElement(StartTagBufferEE
.java:58)
at net.sf.saxon.event.PathMaintainer.endElement(PathMaintainer.java:62)
at net.sf.saxon.event.DocumentValidator.endElement(DocumentValidator.jav
a:68)
at net.sf.saxon.event.ReceivingContentHandler.endElement(ReceivingConten
tHandler.java:459)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endEleme
nt(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImp
l.scanEndElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImp
l$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(U
nknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImp
l.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(U
nknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(U
nknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown So
urce)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Un
known Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.p
arse(Unknown Source)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:427)
at net.sf.saxon.event.Sender.send(Sender.java:138)
at com.saxonica.ee.s9api.SchemaValidatorImpl.validate(SchemaValidatorImp
l.java:587)
at com.saxonica.Validate.processFile(Validate.java:610)
at com.saxonica.Validate.doValidate(Validate.java:416)
at com.saxonica.Validate.main(Validate.java:59)
reported by private email
Related issues
Updated by Michael Kay almost 7 years ago
I'm not getting the problem when I run on the current 9.8 code within IntelliJ. I'm running Validate from the command line which appears to be what the failing run was doing.
Updated by Michael Kay almost 7 years ago
I've also tried on 9.8.0.1, 9.8.0.4, and 9.8.0.7 without reproducing the failure.
One difference I note is that I'm using the Apache Xerces parser rather than the built-in JDK parser, but that seems unlikely to be relevant.
Updated by Michael Kay almost 7 years ago
I noticed that the crash occurs while generating a validity report, so I added a -report:report.xml option to the command line, and this reproduces the crash.
Updated by Michael Kay almost 7 years ago
The main entries in the TinyTree contain 295 used entries, and have an allocated size of 4001. But the "prior" vector has only 167 entries. The prior vector is created lazily on first use, and this should only be done when tree construction is complete. But on this occasion it seems it has been constructed when the tree was incomplete. It looks as if this can happen when we do a streaming validation with assertions: a virtual copy of a subtree of the completed document is constructed for the purpose of evaluating the assertion, and if the assertion uses the preceding-sibling axis, then the prior vector will be built, but only as far as the section of the tree that has already been built.
Updated by Michael Kay almost 7 years ago
So, this is one of those cases where it's clear what's wrong, but it needs careful thought how best to fix it.
I think the simplest fix might be for the method ensurePriorIndex(), which builds the prior vector if it does not already exist, to rebuild the vector if it exists but is incomplete (too short).
Updated by Michael Kay almost 7 years ago
Changing TinyTree.ensurePriorIndex() to
void ensurePriorIndex() {
if (prior == null || prior.length < numberOfNodes) {
makePriorIndex();
}
}
fixes this test case and seems very low-risk. Committing this change.
Updated by Michael Kay almost 7 years ago
- Status changed from New to Resolved
- Applies to branch trunk added
- Fix Committed on Branch 9.8, trunk added
Updated by O'Neil Delpratt over 6 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.10 added
Bug fix applied in the Saxon 9.8.0.10 maintenance release.
Updated by Michael Kay almost 6 years ago
- Has duplicate Bug #4092: java.lang.ArrayIndexOutOfBoundsException when validating with XSD 1.1 with assertion on preceding-sibling added
Please register to edit this issue