Bug #2598: IllegalStateException thrown in DITA-OT 1.8 - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2598

closed

IllegalStateException thrown in DITA-OT 1.8

Added by O'Neil Delpratt almost 9 years ago. Updated almost 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

Internals

Sprint/Milestone:

Start date:

2016-01-26

Due date:

% Done:

Estimated time:

Legacy ID:

Applies to branch:

9.7

Fix Committed on Branch:

9.7

Fixed in Maintenance Release:

9.7.0.3

Platforms:

Description

Reported by Radu Pisoi:

The latest Saxon library (9.7.0.2) throws the exception IllegalStateException with DITA-OT 1.8

D:\workspace_development_branch\eXml-branch-development\frameworks\dita\DITA-OT\build.xml:53: The following error occurred while executing this line:
D:\workspace_development_branch\eXml-branch-development\frameworks\dita\DITA-OT\plugins\org.dita.base\build_preprocess.xml:231: java.lang.IllegalStateException: *** Internal Saxon error: local variable encountered whose binding has been deleted
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:771)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:780)
at net.sf.saxon.style.StyleElement.allocateLocalSlots(StyleElement.java:1640)
at net.sf.saxon.style.XSLTemplate.optimize(XSLTemplate.java:821)
at net.sf.saxon.style.PrincipalStylesheetModule.optimizeTopLevel(PrincipalStylesheetModule.java:1373)
at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1223)
at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:244)
at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:256)
at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:101)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:813)
at net.sf.saxon.jaxp.SaxonTransformerFactory.newTemplates(SaxonTransformerFactory.java:176)

John Lumley reported: I can reproduce this fault from my DITA-OT configuration. Unsurprisingly it only occurs with optimisation (i.e. disappears on -opt:0). Will investigate a bit further.

Actions

Copy link

Updated by O'Neil Delpratt almost 9 years ago

Category set to Internals

Actions

Copy link

Updated by John Lumley almost 9 years ago

A 'minimal' version of this bug seems to be invoked by optimising:

<xsl:template match="*">
    <result>
      <xsl:variable name="element-id" select="@id"/>
      <xsl:value-of select="contains(@href, '://') or $element-id = '#none#' or *[@id = $element-id]"/>
    </result>
  </xsl:template>

which seems to require all three of the or tree leaves. Investigating further.

Actions

Copy link

Updated by John Lumley almost 9 years ago

A little more curiouser:

 <xsl:template match="*">
    <xsl:variable name="element-id" select="@id"/>
    <xsl:value-of select="false() or *[@id = $element-id]"/>
  </xsl:template>

 <xsl:template match="*">
    <xsl:variable name="element-id" select="@id"/>
    <xsl:value-of select="false() or false() or *[@id = $element-id]"/>
 </xsl:template>

Actions

Copy link

Updated by John Lumley almost 9 years ago

Status changed from New to Resolved
Fix Committed on Branch 9.7 added

The root cause is that in optimisation of deep OrExpression trees (@OrExpression.optimize():54@) the attempt to replace with general comparisons is done before the children have been optimised.

Optimisation of children for the working case creates a local variable binding

$Q{http://saxon.sf.net/generated-variable}loc903239994 := data($element-id)

A solution (which might possibly be expensive in deep or trees due to repeated sub-tree optimisation) is to add optimizeChildren() before the attempt to use a general comparison.

The patch has been applied to the 9.7 branch

Actions

Copy link