Bug #2320


"invalid slot number for local variable" error when streaming

Added by Michael Kay about 9 years ago. Updated over 8 years ago.

Start date:
Due date:
% Done:


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


The error "Internal error: invalid slot number for local variable (No slot allocated)" may occur in XSLT stylesheets that use streaming.

Specifically, the error occurs when an expression such as an arithmetic expression has one streaming operand, and another non-streaming operand in which local variables are declared: for example

format-number(. + (let $c := string(../@code) return if ($c castable as xs:double) then number($c) else 0), '0.00')

More specifically by "an expression such as an arithmetic expression" I mean an expression that has no explicit streaming support but uses the fallback mechanisms; this generally means an expression whose operands are atomized and which does not accept multi-item sequences as its operands. Value comparisons probably fall into this category; general comparisons do not.

A test case sx-arithmetic-007 has been created in the XSLT 3.0 test suite.

Actions #1

Updated by Michael Kay about 9 years ago

The internal detail: class StreamingAdjunct contains the fallback code for expressions that do not have custom streaming support. If the expression is not a Callable, the expression is copied, and the streaming argument is replaced with a SuppliedParameterReference which causes the value of the streaming argument to be taken off the stack rather than evaluated in the conventional non-streaming way. But the copied expression does not appear on the expression tree, and therefore it is not visited when (later) slot numbers are allocated to local variables. So at run time an expression with no allocated slots for variables gets evaluated.

There is a TODO comment in the code pointing out this possibility, and I decided to try to construct a test case to see if I could trigger the failure. It has not happened in "real life" as far as we know. The failure still occurs on the 9.7 branch.

Actions #2

Updated by Michael Kay about 9 years ago

For the time being (and this may be the best we can do for 9.6) I've added code to detect the situation and report it cleanly as a situation where streaming is not supported, rather than crashing at execution time.

Actions #3

Updated by Michael Kay about 9 years ago

  • Status changed from In Progress to Resolved

For 9.7 I have fixed the code by replacing the use of SuppliedParameterReference with a new ConsumingOperand object, which differs in that it retains the link to the subexpressions, thus allowing it to be included in the expression tree "in situ". This fix could be retro-fitted to 9.6 if necessary, but in the interests of stability I'll refrain from doing so until the problem arises.

Actions #4

Updated by O'Neil Delpratt about 9 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to

Bug fix applied in the Saxon maintenance release.

Actions #5

Updated by O'Neil Delpratt over 8 years ago

  • Sprint/Milestone set to
  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release added

Please register to edit this issue

Also available in: Atom PDF