Bug #3508
closed
Internal error evaluating template rule (involves xsl:next-match)
Applies to branch:
9.7, 9.8, trunk
Fix Committed on Branch:
9.7, 9.8, trunk
Fixed in Maintenance Release:
Description
Failure with stack trace
java.lang.IndexOutOfBoundsException: Index: 12, Size: 4
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at net.sf.saxon.expr.XPathContextMajor.getTargetComponent(XPathContextMajor.java:693)
at net.sf.saxon.expr.UserFunctionCall.getTargetComponent(UserFunctionCall.java:601)
at net.sf.saxon.expr.UserFunctionCall.callFunction(UserFunctionCall.java:524)
at net.sf.saxon.expr.UserFunctionCall.iterate(UserFunctionCall.java:487)
at net.sf.saxon.expr.Expression.effectiveBooleanValue(Expression.java:868)
at net.sf.saxon.expr.instruct.Choose.choose(Choose.java:902)
at net.sf.saxon.expr.instruct.Choose.processLeavingTail(Choose.java:877)
at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:347)
at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:502)
at net.sf.saxon.trans.TextOnlyCopyRuleSet.process(TextOnlyCopyRuleSet.java:66)
at net.sf.saxon.expr.instruct.NextMatch.processLeavingTail(NextMatch.java:93)
at net.sf.saxon.expr.instruct.Choose.processLeavingTail(Choose.java:880)
Fails with 9.7 and 9.8.
I think the critical factor here is probably that xsl:next-match is called from within a named template, which means that the current component is the named template, while the current mode is the mode of the template rule from which the named template was called. When next-match invokes a built-in template rule, I don't think the current component is being changed, whereas I suspect it needs to become the same as the current mode.
A workaround is to add an explicit template rule equivalent to the built-in rule:
<xsl:template match="node()" priority="-1">
<xsl:apply-templates/>
</xsl:template>
I've made a fix which appears to do the trick subject to further testing: in the process() method of the three relevant BuiltInTemplateRuleSet implementations (ShallowSkip, ShallowCopy, and TextOnly), when creating a new XPathContext object prior to the applyTemplates call, set currentComponent to be the same as currentMode.
It seems that applyTemplates always creates a new XPathContext object even when calling the built-in template rule - it has to, because it might be processing multiple nodes, some with explicit template rules and some with the built-in template rule. NextMatch and ApplyImports, however, don't create a new context object when using the built-in template rule, they rely on the code for the built-in rule to do it when necessary. I think this means that on the applyTemplates path we might be creating two new XPathContext objects, which is an unnecessary cost.
There's definitely a need for more testing here.
- Fix Committed on Branch 9.7, 9.8, trunk added
Patch committed on 9.7, 9.8, and trunk. Further testing needed.
- Status changed from New to Resolved
Now tested by means of additional tests in the next-match test set.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.21 added
Bug fix applied in the Saxon 9.7.0.21 maintenance release.
Bug fix applied in the Saxon 9.8.0.7 maintenance release.
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.8.0.7 added
- Related to Bug #3706: Array out of bounds exception results from function in template predicate added
Please register to edit this issue
Also available in: Atom
PDF
.