Bug #2552: AssertionError during byte code generation - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2552

closed

AssertionError during byte code generation

Added by Gunther Rademacher about 9 years ago. Updated over 8 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Byte code generation

Sprint/Milestone:

9.7.0.3

Start date:

2015-12-18

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.6, 9.7

Fix Committed on Branch:

9.6, 9.7

Fixed in Maintenance Release:

9.7.0.3, 9.6.0.9

Platforms:

Description

Compiling this XQuery

declare function local:f($e, $n) 
{
  if (exists($e)) then
    $e
  else
    local:f(element e {string-join((1 to xs:integer($n/text())) ! "e")}, ())
};
local:f((), <n>10</n>)

with Saxon-EE 9.7.0.1 shows this:

com.saxonica.ee.bytecode.util.CannotCompileException: class net.sf.saxon.expr.instruct.FixedElement: <e {string-join((1 to (Q{http://www.w3.org/2001/XMLSchema}integer(atomizeSingleton(ConditionalSorter(exists(tail(($n) treat as node())), documentSort((($n) treat as node())/child::text())))))) ! "e")}/>
        at com.saxonica.ee.bytecode.LetExpressionCompiler.makeClosure(LetExpressionCompiler.java:630)
        at com.saxonica.ee.bytecode.LetExpressionCompiler.compileCommonExpr(LetExpressionCompiler.java:181)
        at com.saxonica.ee.bytecode.UserFunctionCallCompiler.compileFunctionCall(UserFunctionCallCompiler.java:65)
        at com.saxonica.ee.bytecode.UserFunctionCallCompiler.compileToIterator(UserFunctionCallCompiler.java:21)
        at com.saxonica.ee.bytecode.util.CompilerService.compileToIterator(CompilerService.java:760)
        at com.saxonica.ee.bytecode.ChooseCompiler.compileToIterator(ChooseCompiler.java:42)
        at com.saxonica.ee.bytecode.util.CompilerService.compileToIterator(CompilerService.java:760)
        at com.saxonica.ee.bytecode.TailCallLoopCompiler.compileToIterator(TailCallLoopCompiler.java:21)
        at com.saxonica.ee.bytecode.util.CompilerService.compileToIterator(CompilerService.java:760)
        at com.saxonica.ee.bytecode.util.CompilerService.compileToByteCode(CompilerService.java:508)
        at com.saxonica.ee.optim.OptimizerEE.compileToByteCode(OptimizerEE.java:1524)
        at net.sf.saxon.query.XQueryFunction.optimize(XQueryFunction.java:483)
        at net.sf.saxon.query.XQueryFunctionLibrary.optimizeGlobalFunctions(XQueryFunctionLibrary.java:328)
        at net.sf.saxon.query.QueryModule.optimizeGlobalFunctions(QueryModule.java:1200)
        at net.sf.saxon.expr.instruct.Executable.fixupQueryModules(Executable.java:574)
        at net.sf.saxon.query.XQueryParser.makeXQueryExpression(XQueryParser.java:161)
        at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:589)
        at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:652)
        at net.sf.saxon.s9api.XQueryCompiler.compile(XQueryCompiler.java:606)
        at net.sf.saxon.Query.compileQuery(Query.java:794)
        at net.sf.saxon.Query.doQuery(Query.java:342)
        at net.sf.saxon.Query.main(Query.java:111)
Exception in thread "main" java.lang.AssertionError: The Label: notInstanceOf has been used but not marked
        at com.saxonica.ee.bytecode.util.GeneratedMethodInfo.checkLabels(GeneratedMethodInfo.java:147)
        at com.saxonica.ee.bytecode.util.CompilerService.popCurrentMethodInfo(CompilerService.java:874)
        at com.saxonica.ee.bytecode.util.CompilerService.compileToByteCode(CompilerService.java:526)
        at com.saxonica.ee.optim.OptimizerEE.compileToByteCode(OptimizerEE.java:1524)
        at net.sf.saxon.query.XQueryFunction.optimize(XQueryFunction.java:483)
        at net.sf.saxon.query.XQueryFunctionLibrary.optimizeGlobalFunctions(XQueryFunctionLibrary.java:328)
        at net.sf.saxon.query.QueryModule.optimizeGlobalFunctions(QueryModule.java:1200)
        at net.sf.saxon.expr.instruct.Executable.fixupQueryModules(Executable.java:574)
        at net.sf.saxon.query.XQueryParser.makeXQueryExpression(XQueryParser.java:161)
        at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:589)
        at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:652)
        at net.sf.saxon.s9api.XQueryCompiler.compile(XQueryCompiler.java:606)
        at net.sf.saxon.Query.compileQuery(Query.java:794)
        at net.sf.saxon.Query.doQuery(Query.java:342)
        at net.sf.saxon.Query.main(Query.java:111)

Actions

Copy link

Updated by Michael Kay about 9 years ago

Category set to Byte code generation
Assignee set to Michael Kay
Priority changed from Low to Normal

Interesting. The code that throws the original CannotCompileException is StringToIntegerCompiler.compileToPrimitive(). This code is unchanged since at least 9.4. Normally when someone throws a CannotCompileException it is caught, and execution falls back to interpreted mode. That isn't happening on this path. The culprit appears to be UserFunctionCallCompiler at line 66, which catches the exception, prints a stack trace, and then carries on as if nothing had happened (resulting in the subsequent AssertionError). But this code too has been unchanged since at least 9.4.

What has changed? Answer: the CastExpressionCompiler in 9.6, recognizing that it has to convert UntypedAtomic to Integer, invoked the GenericConverterCompiler to generate code. The CastExpressionCompiler in 9.7 instead invokes the StringToIntegerCompiler, which ought to be smarter, but unfortunately this particular path (compileToPrimitive) is essentially unimplemented, and this was previously going unnoticed.

So it seems we have two things to fix. The UserFunctionCallCompiler ought to handle the exception properly, and the StringToIntegerCompiler should not be generating the exception in the first place.

Actions

Copy link

Updated by Michael Kay about 9 years ago

I have fixed UserFunctionCallCompiler to handle the exception properly, and this is sufficient to make the query execute successfully as far as the user can see. The fact that it has failed and then recovered becomes apparent, however, if the debugByteCode switch is enabled.

Actions

Copy link