Bug #5495
closedjava.lang.UnsupportedOperationException: Cannot copy a variable reference whose binding is unknown
0%
Description
Issue : We are getting below " binding is unknown " exception as in stackTrace while using Saxon-HE 10.8 and 11.3. With version 10.7 no regression is found.
Analysis:
I think the issue is at "/" in xsl:template of our source.xml file. It used to work till 10.7
Steps to reproduce :
Execute command below command using attached source.xml and myXsl.xsl files
java -jar saxon.jar -s:source.xml -xsl:myXsl.xsl
using Saxon-HE 10.8 or higher .
source.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/servlet/MyServlet/*</url-pattern>
</servlet-mapping>
myXsl.xsl file:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"
xmlns="http://java.sun.com/xml/ns/javaee"
xpath-default-namespace="http://java.sun.com/xml/ns/javaee">
<xsl:output method="xml" indent="no" encoding="UTF-8"/>
<xsl:param name="servletName"/>
<xsl:param name="urlPattern" select='concat("/servlet/",$servletName,"/*")'/> <!-- Default to normal servlet URL pattern -->
<xsl:template match="servlet-mapping[servlet-name=$servletName] /
url-pattern[position()=last()]">
</xsl:template>
</xsl:stylesheet>
StackTrace :
java.lang.UnsupportedOperationException: Cannot copy a variable reference whose binding is unknown
at net.sf.saxon.expr.GlobalVariableReference.copy(GlobalVariableReference.java:43)
at net.sf.saxon.expr.Atomizer.copy(Atomizer.java:348)
at net.sf.saxon.expr.GeneralComparison20.copy(GeneralComparison20.java:43)
at net.sf.saxon.expr.FilterExpression.copy(FilterExpression.java:1183)
at net.sf.saxon.expr.SlashExpression.copy(SlashExpression.java:659)
at net.sf.saxon.pattern.GeneralNodePattern.makeTopNodeEquivalent(GeneralNodePattern.java:61)
at net.sf.saxon.pattern.GeneralNodePattern.<init>(GeneralNodePattern.java:47)
at net.sf.saxon.expr.SlashExpression.toPattern(SlashExpression.java:855)
at net.sf.saxon.expr.sort.DocumentSorter.toPattern(DocumentSorter.java:249)
at net.sf.saxon.pattern.PatternMaker.fromExpression(PatternMaker.java:45)
at net.sf.saxon.pattern.PatternParser30.parsePattern(PatternParser30.java:130)
at net.sf.saxon.pattern.Pattern.make(Pattern.java:59)
at net.sf.saxon.style.StyleElement.makePattern(StyleElement.java:723)
at net.sf.saxon.style.XSLTemplate.prepareAttributes(XSLTemplate.java:371)
at net.sf.saxon.style.StyleElement.processAttributes(StyleElement.java:594)
at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:531)
at net.sf.saxon.style.XSLTemplate.processAllAttributes(XSLTemplate.java:428)
at net.sf.saxon.style.PrincipalStylesheetModule.processAllAttributes(PrincipalStylesheetModule.java:589)
at net.sf.saxon.style.PrincipalStylesheetModule.preprocess(PrincipalStylesheetModule.java:366)
at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:288)
at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:252)
at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:113)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:851)
at net.sf.saxon.Transform.doTransform(Transform.java:753)
at net.sf.saxon.Transform.main(Transform.java:82)
Files
Related issues
Updated by Rohit Gaikwad over 2 years ago
Hi Team,
Can someone please take a look into this?
Thanks, --Rohit
Updated by Michael Kay over 2 years ago
Thanks for reporting it.
I've reproduced it as test case variable-4802.
The bug appears to have been introduced as a side-effect of the fix for bug #5369.
As a workaround, please try changing the pattern to
servlet-mapping[servlet-name=$servletName] / url-pattern[not(following-sibling::url-pattern)]
In fact, I would suggest that as a permanent change, since this pattern is what the optimizer is trying to generate anyway, because it enables the pattern to be evaluated without back-tracking.
Updated by Rohit Gaikwad over 2 years ago
Thanks Michael for your quick response!
The workaround is working fine. However, We are migrating from Saxon-B(9.1.x) to Saxon-HE 11.3 where amount of efforts required is huge. There are ~700 xsl files in our project, applying this workaround on applicable xsl files will be an additional cost at this time.
It will be better if this bug fix is available in Saxon-HE 11.4 , As right now our target is to make our codebase compatible with Saxon-HE 11.x. Once, this is achieved then we can look into further optimizations that you provided in the workaround.
Thanks, --Rohit
Updated by Michael Kay over 2 years ago
We'll obviously plan to fix this in the next maintenance release, but we always try to provide a workaround if we can so people can make progress in the meantime.
Updated by Rohit Gaikwad over 2 years ago
Can you please let me know when is the next maintenance release planned? Is it possible to make this fix available ASAP in 11.4?
Thanks, --Rohit
Updated by Michael Kay over 2 years ago
Let's focus on fixing it first. I'm currently working on a couple of problems raised by paying customers so those take priority.
Updated by Michael Kay over 2 years ago
In the solution bug #5369, we modify a GeneralNodePattern to ensure that it matches beneath a parentless element node; to modify an expression or pattern, we have to copy it (because the original might be referenced from elsewhere). The reason we have a GeneralNodePattern
here is because it has a [position()=last()]
predicate which prevents right-to-left evaluation. The copy operation on the pattern fails because of the global variable reference.
The preferred solution is probably to delay the modification/copying of the pattern until the variable reference has been resolved, specifically, until the typeCheck phase.
This works for this test case; now need to regression-test to see what we've broken.
Updated by Michael Kay over 2 years ago
- Status changed from New to In Progress
Unfortunately the fix breaks tests match-273, -274, and -284, all tests introduced in response to bug #5369.
Updated by Michael Kay over 2 years ago
- Priority changed from High to Normal
Fixed: GeneralNodePattern.copy()
needs to copy the topNodeEquivalent
field.
But then variable-4802 fails again.
Updated by Michael Kay over 2 years ago
I've copied the patch to the 10.x branch, but tests match-273, -274, and -284 are still failing.
I think this is because I happened to run them with -export:on, and the rewritten pattern isn't surviving the round trip through a SEF file.
Sure enough, the tests fail with -export:on on the 11.x branch as well.
Fixed by adding a completion action to invoke GeneralNodePattern.makeTopNodeEquivalent()
in the package loader.
Updated by Michael Kay over 2 years ago
- Status changed from In Progress to Resolved
- Applies to branch 11, trunk added
- Fix Committed on Branch 10, 11, trunk added
Updated by Rohit Gaikwad over 2 years ago
Thanks Michael for fixing this issue.
Updated by Debbie Lockett over 2 years ago
- Fixed in Maintenance Release 11.4 added
Bug fix applied in the Saxon 11.4 maintenance release. (Issue remains open awaiting Saxon 10 maintenance release.)
Updated by Michael Kay over 2 years ago
- Has duplicate Bug #5633: Cannot copy a variable reference whose binding is unknown [Saxon 11] added
Updated by Toshihiko Makita about 2 years ago
I do want to get Saxon 10 maintenance release because the newest DITA Open Toolkit uses Saxon 10. The DITA-OT core module dost.jar is tightly combined with Saxon 10 API. As a result, I cannot use our XSLT stylesheet that are developed with old Saxon 9.1B XSLT processor. We still got "Cannot copy a variable reference whose binding is unknown" with Saxon-PE 10.8 with the newest DITA-OT 3.7.2.
Updated by Michael Kay about 2 years ago
- Status changed from Resolved to In Progress
I've re-opened the bug so we can work on a 10.x solution.
Currently in my 10.x development environment, tests
match-273
match-274
match-275
match-278
are failing (but variable-4802 succeeds). So we have some work to do.
Updated by Michael Kay about 2 years ago
I've retrofitted the changes to GeneralNodePattern to the 10.x branch, but sadly these tests are still failing, so I'm probably going to have to debug them from first principles.
(The XSLT3 test suite is currently crashing on 10.x on test (-s:arrays -t:arrays-306) which was added in response to bug #5600, for which the solution in 11.x and 12.x was rather radical. In creating a new maintenance release for 10.x, we need to make a hard-headed decision about which bug fixes to retrofit.)
Updated by Toshihiko Makita about 2 years ago
According to the recommendation, I removed position() function from primary source code. However, included DITA-OT plug-in seems to use it. As a result, I cannot compile my plug-in code with the newest DITA-OT 3.7.3. I'm porting user stylesheet from DITA-OT 1.8.5 (which uses old SaxonB 9.1) to make a new plug-in and now fall into deep pitfall.
transform.merged.common.debug:
[xslt] Processing D:\My_Documents\XML2022\HCM\sample\20220918-consite\temp\pdf\test_consite_task_CONVERTED.xml to D:\My_Documents\XML2022\HCM\sample\20220918-consite\temp\pdf\test_consite_task-pre.fo
[xslt] Loading stylesheet D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\com.hitachi-c-m.consite.fdp.pdf\xsl\csfdp2fo-shell.xsl
[xslt] Failed to process D:\My_Documents\XML2022\HCM\sample\20220918-consite\temp\pdf\test_consite_task_CONVERTED.xml
BUILD FAILED
D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\org.dita.base\build.xml:29: The following error occurred while executing this line:
D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\org.dita.base\build.xml:158: The following error occurred while executing this line:
D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\com.hitachi-c-m.consite.fdp.pdf\build.xml:17: The following error occurred while executing this line:
D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\com.hitachi-c-m.consite.fdp.pdf\build.xml:58: The following error occurred while executing this line:
D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\com.hitachi-c-m.consite.fdp.pdf\build.xml:121: The following error occurred while executing this line:
D:\DITA-OT\dita-ot-3.7.3-hcm\plugins\com.hitachi-c-m.consite.fdp.pdf\build.xml:185: java.lang.UnsupportedOperationException: Cannot copy a variable reference whose binding is unknown
at net.sf.saxon.expr.GlobalVariableReference.copy(GlobalVariableReference.java:43)
at net.sf.saxon.expr.FilterExpression.copy(FilterExpression.java:1183)
at net.sf.saxon.expr.SlashExpression.copy(SlashExpression.java:659)
at net.sf.saxon.pattern.GeneralNodePattern.makeTopNodeEquivalent(GeneralNodePattern.java:61)
at net.sf.saxon.pattern.GeneralNodePattern.<init>(GeneralNodePattern.java:47)
at net.sf.saxon.expr.SlashExpression.toPattern(SlashExpression.java:855)
at net.sf.saxon.expr.sort.DocumentSorter.toPattern(DocumentSorter.java:249)
at net.sf.saxon.pattern.PatternMaker.fromExpression(PatternMaker.java:45)
at net.sf.saxon.pattern.PatternParser30.parsePattern(PatternParser30.java:130)
at net.sf.saxon.pattern.Pattern.make(Pattern.java:59)
at net.sf.saxon.style.StyleElement.makePattern(StyleElement.java:723)
at net.sf.saxon.style.XSLTemplate.prepareAttributes(XSLTemplate.java:371)
at net.sf.saxon.style.StyleElement.processAttributes(StyleElement.java:594)
at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:531)
at net.sf.saxon.style.XSLTemplate.processAllAttributes(XSLTemplate.java:428)
at net.sf.saxon.style.PrincipalStylesheetModule.processAllAttributes(PrincipalStylesheetModule.java:589)
at net.sf.saxon.style.PrincipalStylesheetModule.preprocess(PrincipalStylesheetModule.java:366)
at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:288)
at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:252)
at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:113)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:851)
at net.sf.saxon.jaxp.SaxonTransformerFactory.newTemplates(SaxonTransformerFactory.java:154)
at org.apache.tools.ant.taskdefs.optional.TraXLiaison.readTemplates(TraXLiaison.java:298)
at org.apache.tools.ant.taskdefs.optional.TraXLiaison.createTransformer(TraXLiaison.java:311)
at org.apache.tools.ant.taskdefs.optional.TraXLiaison.transform(TraXLiaison.java:187)
at org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:870)
at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:408)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.Project.executeTarget(Project.java:1374)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.Main.runBuild(Main.java:818)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
Total time: 5 seconds
The process finished with exit code: 1
Updated by Toshihiko Makita about 2 years ago
Is there any further workaround to escape this error?
Updated by Michael Kay about 2 years ago
We've been planning for a while to get back to doing a new (and probably final) maintenance release on the 10.x branch but there have been too many other priorities. It's still on our TODO list.
Updated by Michael Kay over 1 year ago
- Fixed in Maintenance Release 10.9 added
- Fixed in Maintenance Release deleted (
11.4)
We produced a new maintenance release on the 10.x branch in February 2023. Hopefully that fixed this problem, and leaving the issue open was merely an administrative oversight. I would be grateful for confirmation as to whether the problem still exists with Saxon 10.9. Meanwhile, closing it again.
Updated by Michael Kay over 1 year ago
- Status changed from In Progress to Closed
Please register to edit this issue