-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Storage Execution
-
173
If you drop a collection and then insert into that collection (or potentially perform some other operation) in the same WUOW, when the onCommit handlers run there will be a heap-use-after-free because the CollectionImpl::_shared was already destructed by the onCommit of the drop.
The heap-use-after-free could be fixed easily by capturing CollectionImpl::_shared by value in the onCommit handlers, but I think conceptually this order of operations shouldn't have this behavior; since the insert came after the drop, it doesn't make sense to "insert" into the dropped collection.
Another option could be to make an implicit collection creation occur in this case, however I think this could result in some subtle confusing behavior. The caller may be trying to drop a collection that it had previously created with some special settings, but then after the drop seemingly succeeded it would be recreated with default settings.
A third option is to make this a more obvious failure so that callers know to not do this. Currently this misbehavior is only consistently observed on ASAN builds. If we explicitly disallow operating on a collection in the same WUOW after dropping it, these misuses can be caught earlier.