Project

Profile

Help

Bug #4999

closed

9.5 EE compilation fails but OK with Professional

Added by Taras Chervinka almost 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2021-05-25
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
9.5
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

The test with 9.5-ee jar fails with EnterpriseConfiguration but passes with Professional

Run the attached and see the error. change to PC and see that compilation passes

*** Internal Saxon error: local variable encountered whose binding has been deleted
Variable name: zz:zz2017354584
Line number of reference: 3 in *module with no systemId*
Line number of declaration: 3 in *module with no systemId*
DECLARATION:
<let variable="Q{http://saxon.sf.net/}zz2017354584"
     as="element()"
     slot="-999">
  <be>
    <treat as="element()">
      <checkCardinality occurs="exactly one">
        <variableReference name="wsdlDoc" slot="2"/>
      </checkCardinality>
    </treat>
  </be>
  <return>
    <slash>
      <treat as="node()">
        <variableReference name="wsdlDoc" slot="2"/>
      </treat>
      <filterExpression>
        <axis name="child" nodeTest="element(Q{}binding)"/>
        <indexedLookup>
          <variableReference name="Q{http://saxon.sf.net/}zz1935637221" slot="0"/>
          <functionCall name="local-name-from-QName">
            <functionCall name="resolve-QName">
              <convertUntyped to="xs:string">
                <data>
                  <axis name="attribute" nodeTest="attribute(Q{}type)"/>
                </data>
              </convertUntyped>
              <variableReference name="Q{http://saxon.sf.net/}zz2017354584" slot="-999"/>
            </functionCall>
          </functionCall>
        </indexedLookup>
      </filterExpression>
    </slash>
  </return>
</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:614)
        at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:624)
        at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:624)
        at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:624)
        at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:624)
        at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:624)
        at net.sf.saxon.expr.parser.ExpressionTool.allocateSlots(ExpressionTool.java:624)
        at net.sf.saxon.query.XQueryExpression.<init>(XQueryExpression.java:98)
        at net.sf.saxon.query.QueryParser.makeXQueryExpression(QueryParser.java:183)
        at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:526)
        at net.sf.saxon.s9api.XQueryCompiler.compile(XQueryCompiler.java:494)
        at CompileTest.testCompile(CompileTest.java:60)
        at CompileTest.main(CompileTest.java:69)

Files

CompileTest.java (2.03 KB) CompileTest.java Taras Chervinka, 2021-05-25 17:02
Actions #1

Updated by Taras Chervinka almost 3 years ago

the same passes with 10.5 ee

Actions #2

Updated by Michael Kay almost 3 years ago

I'm sorry, but we are no longer fixing bugs in Saxon 9.5, which was released in 2013.

It's almost certainly an optimiser problem, so if you can't move forward to a later release, you might be able to workaround it by disabling selected optimisations using the -opt option.

But I would strongly suggest moving forward. Apart from anything else, Saxon 9.5 predates the final version of the W3C specifications, so you're working with a product that implements draft specs.

Actions #3

Updated by Taras Chervinka almost 3 years ago

we are moving to 10x. but for some time need to support 9.5 can you suggest which optimization needs to be turned off?

Actions #4

Updated by Michael Kay almost 3 years ago

I'm not sure whether 9.5 allowed very selective control over optimisations, I have a feeling that's something we introduced later.

The trace shows an indexedLookup expression that results from optimising something like $binding[@type=XXXX], so your best approach might be to find this expression and artificially prevent the optimisation by complicating the expression, e.g. to something like $binding[position() gt 100000000 or @type=XXXX],

Actions #5

Updated by Taras Chervinka almost 3 years ago

fixed the case by moving binding part to a function.

let $f:=function($s, $wsdl){local-name-from-QName(resolve-QName($s, $wsdl))}
let $bindingForPortType := $wsdlDoc/wsdl:binding[$f(@type,$wsdlDoc)=$portTypeName]

but we have plenty of "Internal Saxon error: local variable encountered whose binding has been deleted" exceptions and each case needs some time to find and fix. Moreover, there are some expressions that cannot be fixed as written by customers so we have no control over them.

Actions #6

Updated by Michael Kay almost 3 years ago

Have you checked that you are using the latest maintenance release on the 9.5 branch (namely 9.5.1.10)? I thought it had reached a good level of stability before we moved on.

Actions #7

Updated by Taras Chervinka almost 3 years ago

yes we are on 9.5.1.10 EE

Actions #8

Updated by Taras Chervinka almost 3 years ago

noticed this issue after movement from 9.5.1.10 PE to EE version

Actions #9

Updated by Michael Kay almost 3 years ago

  • Status changed from New to Closed
  • Assignee set to Michael Kay

I'm closing this on the grounds that 9.5 is no longer a supported release. We're happy to provide general advice on moving forwards to a later release, but we can't investigate bugs in 9.5 that are no longer present in 10.x.

Please register to edit this issue

Also available in: Atom PDF