Bug #3069
closed[Saxon 9.7] Internal Saxon error: local variable encountered whose binding has been deleted
100%
Description
Hi,
We are getting an internal Saxon error when trying to run a stylesheet, which we never encountered with previous Saxon releases (we were using Saxon-EE 9.5.1.5J before).
The error is:
Internal Saxon error: local variable encountered whose binding has been deleted
I reproduced the bug in the attached files.
Basically, we have a main stylesheet (testCase.xsl) which imports a lot of functions (lotsOfFunctions.xsl). Whether theses functions are actually called or not does not seems to be the issue.
When trying to run the template testCase with Saxon-EE 9.7.0.13J, we are getting the error below :
*** Bad parent pointer found in 0 at 21 ***
*** Bad parent pointer found in 0 at 21 ***
*** Internal Saxon error: local variable encountered whose binding has been deleted
Variable name: fctstr
Line number of reference: 21 in file:/C:/testCase.xsl
Line number of declaration: 31 in file:/C:/testCase.xsl
DECLARATION:
<?xml version="1.0" encoding="utf-8"?>
<let vn="20" baseUri="file:/C:/testCase.xsl" ns="xs=http://www.w3.org/2001/XMLSchema xsl=http://www.w3.org/1999/XSL/Transform els=http://www.lefebvre-sarrut.eu/ns/els xd=http://www.oxygenxml.com/ns/doc/xsl" line="31" var="fctstr" as="xs:string" slot="-999" eval="-1">
<varRef name="fctstr1" slot="0"/>
<switch line="21">
<varRef role="value" line="31" name="fctstr1" slot="0"/>
<case>
<str val="b"/>
<int val="2"/>
</case>
<case>
<str val="c"/>
<int val="3"/>
</case>
<case>
<str val="a"/>
<int val="1"/>
</case>
<int role="default" val="0"/>
</switch>
</let>
java.lang.IllegalStateException: *** Internal Saxon error: local variable encountered whose binding has been deleted
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:785)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:794)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:794)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:794)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:794)
at net.sf.saxon.style.StyleElement.allocateLocalSlots(StyleElement.java:1586)
at net.sf.saxon.style.XSLFunction.optimize(XSLFunction.java:440)
at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1208)
at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:264)
at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:260)
at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:101)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:859)
at net.sf.saxon.Transform.doTransform(Transform.java:727)
at net.sf.saxon.Transform.main(Transform.java:77)
Fatal error during transformation: java.lang.IllegalStateException: *** Internal Saxon error: local variable encountered whose binding has been deleted
The weird thing is that if I comment some functions in lotsOfFunctions.xsl, the error is gone.
Thank you for your time investigating this!
Files
Updated by O'Neil Delpratt almost 8 years ago
- Status changed from New to In Progress
- Priority changed from Low to Normal
Thank you for reporting the problem you have found. I unable to reproduce it. If you are running Saxon from the command-line please can you paste the command you have used?
Thanks
Updated by Axel Court almost 8 years ago
Here is the command line i used:
java -Xms512m -Xmx1024m -classpath C:\saxon97ee\saxonee-9.7.0.13.jar; net.sf.saxon.Transform -versionmsg:off -warnings:silent -expand:off -it:testCase -xsl:testCase.xsl
Thanks
Updated by Michael Kay almost 8 years ago
I reproduced the problem running using the issued 9.7.0.14 Saxon-EE jar file from the command line; the problem does not occur when running the test case in our development/debugging environment.
The diagnostics suggest that it's caused by (some kind of failure during) optimization of the xsl:choose on line 20 of testCase.xsl (because all branches have the same form $v=X, it generates a switch expression which uses hashing rather than a sequential search). As a workaround, you could suppress this optimization by adding a dummy branch to the xsl:choose, e.g. xsl:when test="current-date() lt xs:date('1900-01-01').
I've no idea why it's affected by the contents of the included stylesheet, but it's not unusual for bugs during tree rewrite optimizations to be very sensitive to the exact details of the stylesheet.
Updated by Axel Court almost 8 years ago
Thank you for the workaround, I have tested it in our stylesheet and it works well!
Updated by Michael Kay almost 8 years ago
We have now established that this fails running in the IDE under JDK 1.6, though it succeeds under JDK 1.8.
(This doesn't necessarily imply a bug in Java. We've had this situation before when it turned out that the failure happened when we processed function declarations in a particular order, and the order of processing depended on the exact contents of a hash table, which is inherently unpredictable. This would also explain why the presence of unrelated functions in the stylesheet affects the outcome.)
Updated by Michael Kay almost 8 years ago
- Category set to Internals
- Status changed from In Progress to Resolved
- Assignee set to Michael Kay
- Applies to branch 9.8 added
- Fix Committed on Branch 9.7, 9.8 added
The function els:trans() is (a) optimized to create a switch expression (which evaluates xsl:choose using a hash index), and (b) inlined within the two calls from els:compare(). Inlining a function involves copying its code, and the optimized switch expression is being copied incorrectly - the same variable reference ends up being referenced from both copies, which means that in one copy, the variable binding is unused and is therefore deleted.
The problem occurs if the function is optimized before being inlined, than is, if els:trans() is processed before els:compare(), but it does not occur if the inlining happens first. The order in which functions are optimized depends on their internal ordering in a hash table, which is unpredictable.
Patch being committed to SwitchExpression.copy() on the 9.7 and 9.8 branches.
Updated by O'Neil Delpratt almost 8 years ago
- Category changed from Internals to Byte code generation
Updated by O'Neil Delpratt almost 8 years ago
- Category changed from Byte code generation to Internals
Updated by O'Neil Delpratt almost 8 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.15 added
Bug fix applied to the Saxon 9.7.0.15 maintenance release
Updated by O'Neil Delpratt over 7 years ago
- Fix Committed on Branch trunk added
- Fix Committed on Branch deleted (
9.8)
Please register to edit this issue