Project

Profile

Help

Bug #4999

9.5 EE compilation fails but OK with Professional

Added by Taras Chervinka 2 months ago. Updated about 2 months 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:

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)
CompileTest.java (2.03 KB) CompileTest.java Taras Chervinka, 2021-05-25 17:02

History

#1 Updated by Taras Chervinka 2 months ago

the same passes with 10.5 ee

#2 Updated by Michael Kay 2 months 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.

#3 Updated by Taras Chervinka 2 months 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?

#4 Updated by Michael Kay 2 months 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],

#5 Updated by Taras Chervinka 2 months 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.

#6 Updated by Michael Kay 2 months 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.

#7 Updated by Taras Chervinka 2 months ago

yes we are on 9.5.1.10 EE

#8 Updated by Taras Chervinka 2 months ago

noticed this issue after movement from 9.5.1.10 PE to EE version

#9 Updated by Michael Kay about 2 months 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