Project

Profile

Help

Bug #3069

[Saxon 9.7] Internal Saxon error: local variable encountered whose binding has been deleted

Added by Axel Court almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2016-12-13
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.7
Fix Committed on Branch:
9.7, trunk
Fixed in Maintenance Release:

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!

testCase.xsl (1.14 KB) testCase.xsl Main stylesheet Axel Court, 2016-12-13 12:46
lotsOfFunctions.xsl (10.6 KB) lotsOfFunctions.xsl Axel Court, 2016-12-13 12:46

History

#1 Updated by O'Neil Delpratt almost 5 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

#2 Updated by Axel Court almost 5 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

#3 Updated by Michael Kay almost 5 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.

#4 Updated by Axel Court almost 5 years ago

Thank you for the workaround, I have tested it in our stylesheet and it works well!

#5 Updated by Michael Kay almost 5 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.)

#6 Updated by Michael Kay almost 5 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.

#7 Updated by O'Neil Delpratt almost 5 years ago

  • Category changed from Internals to Byte code generation

#8 Updated by O'Neil Delpratt almost 5 years ago

  • Category changed from Byte code generation to Internals

#9 Updated by O'Neil Delpratt over 4 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

#10 Updated by O'Neil Delpratt over 4 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)

#11 Updated by O'Neil Delpratt over 4 years ago

  • Applies to branch deleted (9.8)

Please register to edit this issue

Also available in: Atom PDF