[SERVER-66930] Improve handling of performing operations on a collection after dropping it in the same WUOW Created: 01/Jun/22  Updated: 26/Apr/23

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Gregory Noma Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Storage Execution
Participants:
Linked BF Score: 173

 Description   

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.


Generated at Thu Feb 08 06:06:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.