Bug #2547: Cannot execute xsl:stream when optimization has been disabled - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2547

closed

Cannot execute xsl:stream when optimization has been disabled

Added by Gunther Rademacher almost 9 years ago. Updated almost 9 years ago.

Status:

Closed

Priority:

Low

Assignee:

Category:

Streaming

Sprint/Milestone:

Start date:

2015-12-17

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7

Fix Committed on Branch:

9.7

Fixed in Maintenance Release:

9.7.0.2

Platforms:

Description

This query

let $x := saxon:stream(doc('doc.xml')/*/*)[1] return $x

works OK when executed from the command line. But when plugged into the test that is attached to #2546, it throws an exception:

net.sf.saxon.s9api.SaxonApiUncheckedException: Cannot execute xsl:stream when optimization has been disabled
	at net.sf.saxon.s9api.XQueryEvaluator.iterator(XQueryEvaluator.java:486)
	at StreamingXQuery.testStreamingQueries(StreamingXQuery.java:115)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
	at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
	at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
Caused by: net.sf.saxon.trans.XPathException: Cannot execute xsl:stream when optimization has been disabled
	at com.saxonica.ee.stream.StreamInstr.processLeavingTail(StreamInstr.java:366)
	at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:149)
	at com.saxonica.ee.stream.PushToPull$Provider.run(PushToPull.java:92)
	at java.lang.Thread.run(Thread.java:745)

Actions

Copy link

Updated by Michael Kay almost 9 years ago

Problem reproduced. It's one of these cases where the code is making a rather wild guess as to the cause of the observed irregularity:

    if (action == null) {

        throw new XPathException("Cannot execute xsl:stream when optimization has been disabled", ...);

    }

So the message is a red herring; we need to find why action is null, and also think about improving the diagnostics.

Actions

Copy link

Updated by Michael Kay almost 9 years ago

The "action" here is the inversion of the body of the xsl:stream instruction; Saxon is assuming that because this inversion is created during the optimization phase, its absence implies that the optimization phase has not been run.

In fact what has happened here is that the xsl:stream instruction, after optimization, has been copied, presumably as part of the standard rewrite that turns "for $x in X return $x" into simply "X"; and during this copy operation, the "action" (the inverted body) has been dropped.

(The term "inversion" here refers to Jackson inversion, a process that converts pull-based code to push-based code).

Actions

Copy link

Updated by Michael Kay almost 9 years ago

Actually, this query is not doing "for $x in X return $x", it is doing "let $x := X return $x", which results in a similar optimisation to "X", but involving an unnecessary copy of X. So we need to fix the fact that xsl:stream is losing its inversion during a copy operation, but we should also avoid the unnecessary copy (FLWORExpression.java line 506).

I have moved this "unnecessary copy" problem to a separate bug entry #2556.

Actions

Copy link

Updated by Michael Kay almost 9 years ago

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

I have committed a patch which ensures that when an xsl:stream instruction is copied, and the inversion of the instruction body has already been computed, then the new (copied) instruction also has its inversion computed.

Actions

Copy link