-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Query Execution
-
Fully Compatible
Remove cross-stage use of SlotAccessor::copyOrMoveValue.
copyOrMoveValue is unsafe when combined with loopy or unwindy stages and can lead to segfaults:
slot_moving_stage // if this stage discard the value moved from scan stage, it will leave invalid view that will result in segfault nlj outer: scan inner: coscan limit 2
buffering and keep the value in scope until EOF or child EOF is insufficient, and will segfault when combined with correlated variables:
nlj outer: scan inner: slot_moving_stage // if this stage moves value from scan stage, and is closed, it will leave invalid view that will result in segfault coscan limit 2
Similar problem exists in PlanExecutor use of copyOrMoveValue. This optimization targets the mkObj + PlanExecutor combination, where we want to avoid making extra copy when converting result bsonObject into Document.
Instead introduce a new SlotAccessor that is capable of interop with Document, like so:
DocumentSlotAccessor : SlotAccessor {
// get view
// etc. Document getDocument() {
if (!_document) {
// move from slot to document. keep the view in slot.
}
return _document; // the slot is now also holding the refcount, so that the value does not go away prematurely.
}
}
PlanExecutorSBE {
getNext(Document* out) {
if (_documentSlotAccessor) {
*out = _documentSlotAccessor.getDocument();
} else {
do the copy
}
}
}
This issue also causes segfault when combined with yielding that performs save/restore, as save may attempt to make a copy of a previously owned bsonObject that got moved and discarded.
- is depended on by
-
-
- Closed
-
- is related to
-
-
- Open
-