Bug #3966
closed
Internal error evaluating template rule (override-v-015)
Category:
XSLT 3.0 packages
Fix Committed on Branch:
9.9
Fixed in Maintenance Release:
Description
Running test set override
test case override-v-015
using the XSLT test runner, we get an internal exception trying to locate a component (indexOutOfBoundsException in XPathContextMajor.getTargetComponent).
- Status changed from New to In Progress
The failure occurs when evaluating the variable reference at line 14 in -015b. The current component is correctly set to the "overridden" version of the "transform" mode associated with package -015a, but the binding vector in this component has length zero, which is incorrect. The base component (the "transform" mode associated with package -015b) correctly has a binding vector of length 2.
The problem seems to be that the used package (-015b) is compiled with JIT enabled for template rules, but we are trying to allocate binding slots to the external references in the template rules, which are not yet available. I think there is logic somewhere to allocate binding slots incrementally as template rules are compiled, but it's not getting invoked in this case.
I have reproduced the error running the test from the command line (with the -lib option). Though it doesn't occur when running from the Java test driver. This is going to make things a lot easier to debug.
- Status changed from In Progress to Resolved
- Applies to branch 9.9 added
- Fix Committed on Branch 9.9 added
When the test is run from the Java test driver, the template rules in the library package are compiled eagerly (even with -jit:on), because at the point where XSLTemplate.compileDeclaration() is called, compilation.isLibraryPackage()
returns true (and therefore isDeferredCompilation()
returns false). This flag is set by XsltCompiler.compilePackage()
.
When running from the command line, and from fn:transform() with a configuration file, the library package is compiled using PackageLibrary.obtainLoadedPackage()
, and this flag is not set.
Setting Compilation.setLibraryPackage(true)
on this path solves the problem for both the command line and the fn:transform() case.
Patch being committed for 9.9 only.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.0.2 added
Bug fix applied to the Saxon 9.9.0.2 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF