Bug #4999
closed9.5 EE compilation fails but OK with Professional
0%
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
Updated by Michael Kay over 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.
Updated by Taras Chervinka over 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?
Updated by Michael Kay over 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]
,
Updated by Taras Chervinka over 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.
Updated by Michael Kay over 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.
Updated by Taras Chervinka over 3 years ago
noticed this issue after movement from 9.5.1.10 PE to EE version
Updated by Michael Kay over 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