Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.1.4, 7.1.5
-
Untriaged
-
0
-
Unknown
Description
The problem is the deferred releaseValues() call in RunOnce(). When runConsumer() returns the operator is available for reuse and the go-routine may be suspended before the rest (i.e. the deferred releaseValues() call) gets to run (function boundary). This leads to cases where the next user of the operator has started using it when the first execution's deferred releaseValues() call gets to execute, corrupting the second legitimate execution.
The problem has been lying in wait since 2015 and MB-15569's code. (Doesn't affect 7.6+ as much since Order changed to use the spillable container.)
(The particular statement that revealed the problem did so because the subsequent executions were quick - the source for the sub-queries being just a document field so they're quickly in their sorting when the values are incorrectly released under them.)
afterItems() is the correct place to - and indeed does - clean up values; the active execution "owns" the operator for the entirety of its duration. But this is only for normal execution. Error conditions (and serialised sending) need clean-up too. Whilst just removing the redundant calls does address the problem for this case there should be the ability to specify specific clean-up to take place before "ownership" is relinquished.
Attachments
Issue Links
- is a backport of
-
MB-58918 Panic (SEGV or array index out of bounds) under Order.afterItems or Order.processItem
- Closed