Bug #1981
closedGROUP BY for a collection of map fails unless wrapped in a try-catch
Added by Ed Gimzewski almost 11 years ago. Updated almost 11 years ago.
100%
Description
As illustrated in the attached file, below works OK if wrapped in a try/catch but fails if unwrapped, with a "local variable $m cannot be allocated a stack frame slot".
let $coll_of_maps := ( map{a":=1,"b":=2}, map{"a":=1,"b":=3}, map {"a":=2,"b":=2}, map {"a":=2,"b":=4},map {"a":=3,"b)
for $m in $coll_of_maps let $a := $m('a') group by $a return map { key":=$a , "members }
Files
group_by_map.xq (918 Bytes) group_by_map.xq | Ed Gimzewski, 2014-01-16 01:25 | ||
run_saxon_to_screen.text (263 Bytes) run_saxon_to_screen.text | Ed Gimzewski, 2014-01-16 11:19 |
Updated by Michael Kay almost 11 years ago
- Assignee set to Michael Kay
- Priority changed from Low to Normal
Thanks for reporting this. I'm afraid I haven't been able to reproduce it. Can you give more details of exactly how you were running the query?
Updated by Ed Gimzewski almost 11 years ago
- File run_saxon_to_screen.text run_saxon_to_screen.text added
Hi
I am running via the attached bat file (renamed as .txt ).
The error when not trapped is:
C:\Program Files (x86)\Notepad++>"C:\Program Files\Java\jre7\bin\java" -d64 -Xms256m -Xmx6148m -classpath "C:\Users\egimzews\Downloads\Saxonica\9_5_1\Saxo
nEE9-5-1-3J\saxon9ee.jar";"C:\Users\egimzews\Downloads\Saxonica\9_5_1\SaxonEE9-5-1-3J\lic" net.sf.saxon.Query -qversion:3.0 -q:"C:\Users\egimzews\AppData\X
QueryProjects\projects\playpen\group_by_map.xq"
java.lang.ArrayIndexOutOfBoundsException: Local variable $m has not been allocated a stack frame slot
at net.sf.saxon.expr.LocalVariableReference.evaluateVariable(LocalVariableReference.java:102)
at net.sf.saxon.expr.VariableReference.iterate(VariableReference.java:457)
at net.sf.saxon.functions.IntegratedFunctionCall.iterate(IntegratedFunctionCall.java:262)
at net.sf.saxon.expr.instruct.BlockIterator.next(BlockIterator.java:49)
at com.saxonica.functions.map.MapNew$MapNewCall.call(MapNew.java:168)
at net.sf.saxon.functions.IntegratedFunctionCall.iterate(IntegratedFunctionCall.java:268)
at net.sf.saxon.expr.flwor.ReturnClauseIterator.next(ReturnClauseIterator.java:58)
at net.sf.saxon.value.SequenceExtent.<init>(SequenceExtent.java:112)
at net.sf.saxon.value.SequenceExtent.makeSequenceExtent(SequenceExtent.java:158)
at com.saxonica.functions.xpath3.SerializeJsonFn.evalSerializeJson(SerializeJsonFn.java:74)
at com.saxonica.functions.xpath3.SerializeJsonFn.call(SerializeJsonFn.java:70)
at CE_main_1416657330.process(file:/C:/Users/egimzews/AppData/XQueryProjects/projects/playpen/group_by_map.xq:28)
at com.saxonica.bytecode.CompiledExpression.process(CompiledExpression.java:60)
at net.sf.saxon.query.XQueryExpression.run(XQueryExpression.java:418)
at net.sf.saxon.Query.runQuery(Query.java:887)
at net.sf.saxon.Query.doQuery(Query.java:399)
at net.sf.saxon.Query.main(Query.java:107)
Fatal error during query: java.lang.ArrayIndexOutOfBoundsException: Local variable $m has not been allocated a stack frame slot
C:\Program Files (x86)\Notepad++>pause
Press any key to continue . . .
tel desk +44 203 530 1024 / mobile +44 7766 520 692
Skype: ed.gimzewski-----Saxonica Developer Community <dropbox+saxonica+f38e@plan.io> wrote: -----
To: undisclosed-recipients:From: Saxonica Developer Community <dropbox+saxonica+f38e@plan.io>
Date: 16.1.2014 09:42Subject: [Saxon - Bug #1981] GROUP BY for a collection of map fails unless wrapped in a try-catch
Updated by Michael Kay almost 11 years ago
Thanks. We have now reproduced the problem on a different machine. I think they are executing the same code; I'm pursuing a theory that there's a dependency on order of evaluation which is unpredictable because the post-grouping tuples use a hash table for the variable bindings. At any rate, it's strongly related to the use of "group by" and probably has nothing to do with maps.
Updated by Michael Kay almost 11 years ago
We've worked out why the two machines differed: in my first attempts I removed the unused variable $grouping_trapped, and the failure only occurs if this variable is present in the query. Very strange, but at least we now have repeatable behaviour.
Updated by Michael Kay almost 11 years ago
- Category set to XQuery conformance
- Status changed from New to Resolved
- Found in version changed from Enterprise 9.5.1.3 to 9.5
The problem occurs when a FLWOR expression containing a group by clause is copied; in this case it is copied as part of the optimization of the containing FLWOR expression, which is rewritten to remove the unused let clause. When the group by clause is copied, the reference count for the implicitly declared variables (the post-grouping variables) in the group by clause is reset to zero, and when this rewritten group by clause is then optimized again, the reference count of zero triggers removal of the variable binding from the expression tree.
A patch is being committed on the 9.5 and 9/6 branches (method LocalVariableBinding.copy()).
Updated by Ed Gimzewski almost 11 years ago
Many thanks for the quick response.
FYI: We are assessing XQuery 3.0 for processing JSON docs in a Mongo database.
A simple extension function in our XQuery lets us get/put a collection of documents from/to Mongo (using parse-json, serialize-json) via the Mongo Java driver
In XQuery we process the collection as maps.
We are exploring processing very large collections in chunks using XQuery tumbling windows (e.g. 1000 wide); i.e. to get
subsets that are manageable with our simple Mongo i/o function.
The alternative is Clojure, which is very good with maps too, but Clojure lacks the XML namespace support required elsewhere in our project.
tel desk +44 203 530 1024 / mobile +44 7766 520 692Skype: ed.gimzewski
-----Saxonica Developer Community <dropbox+saxonica+f38e@plan.io> wrote: -----
To: undisclosed-recipients:From: Saxonica Developer Community <dropbox+saxonica+f38e@plan.io>
Date: 16.1.2014 13:05Subject: [Saxon - Bug #1981] (Resolved) GROUP BY for a collection of map fails unless wrapped in a try-catch
Updated by O'Neil Delpratt almost 11 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.5.1.4
Bug fix applied in Saxon maintenance release 9.5.1.4
Please register to edit this issue