Bug #3966
closed
Internal error evaluating template rule (override-v-015)
100%
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).
Updated by Michael Kay over 5 years ago
- 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.
Updated by Michael Kay over 5 years ago
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.
Updated by Michael Kay over 5 years ago
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.
Updated by Michael Kay over 5 years ago
- 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.
Updated by O'Neil Delpratt over 5 years ago
- 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
.