Bug #2571: XQuery group-by leads to "Local variable $x has not been allocated a stack frame slot" - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2571

closed

XQuery group-by leads to "Local variable $x has not been allocated a stack frame slot"

Added by Michael Kay over 8 years ago. Updated almost 8 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

XQuery conformance

Sprint/Milestone:

9.7.0.3

Start date:

2016-01-05

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

Reported by Hans-Juergen Rennau in email to MHK. The query:

let $doc := doc('problem-input.xml')

let $targets :=

for $xincludeGroup in $doc//xi:include

group by $href := $xincludeGroup/@href

order by $href

return <target href="{$href}"/>

return

<targets>{$targets}</targets>

fails with:

java.lang.ArrayIndexOutOfBoundsException: Local variable $xincludeGroup has not been allocated a stack frame slot

at net.sf.saxon.expr.LocalVariableReference.evaluateVariable(LocalVariableReference.java:114)

at net.sf.saxon.expr.flwor.TupleExpression.evaluateItem(TupleExpression.java:122)

at net.sf.saxon.expr.flwor.OrderByClausePush.processTuple(OrderByClausePush.java:50)

at net.sf.saxon.expr.flwor.GroupByClausePush.close(GroupByClausePush.java:100)

at net.sf.saxon.expr.flwor.LetClausePush.close(LetClausePush.java:44)

at net.sf.saxon.expr.flwor.ForClausePush.close(ForClausePush.java:53)

The problem occurs in the latest 9.6 build but not in 9.7

Actions

Copy link

Updated by Michael Kay over 8 years ago

Description updated (diff)

Actions

Copy link

Updated by Michael Kay over 8 years ago

What seems to be happening is as follows. In theory, there should be both a pre-grouping value for $xincludeGroup (containing a single item, the value before the group-by processing) and a post-grouping value with the same variable name, holding the set of all the values for the group. Because there is no reference to the post-grouping variable of this name, it seems to have been optimized away (and therefore, not allocated a slot number). But the order by clause doesn't seem aware that the variable has been optimized away; its TupleExpression is expected to contain a binding for this variable.

Actions

Copy link

Updated by Michael Kay over 8 years ago

During optimization of the outer FLWOR expression, the variable $targets is inlined. As described in bug #2556, this results in an unnecessary (but not intrinsically incorrect) copy operation on the inner FLWOR expression. This copy operation has a bug: the LocalVariableBinding objects used to represent the synthetic post-grouping variables (specifically the post-grouping version of the $xincludeGroup variable) have their reference counts set to zero. The reference counts are not recomputed after the rewrite, and consequently in the next phase of optimization the variable binding is considered to be unreferenced and is therefore dropped (without, of course, removing the reference to the variable).

Fixing the copy() operation on LocalVariableReference to preserve the reference count appears to solve the problem (but not yet regression-tested).

On the 9.7 branch, the problem no longer surfaces because the fix to bug #2556 eliminates the unnecessary copy operation. However, the copy() operation on LocalVariableReference is still incorrect, it just doesn't get exercised by this test case. I think it is therefore prudent to apply the same patch.

Actions

Copy link