[SERVER-66439] Concurrent `checkIfOptionsConflict` running while state doc is being updated Created: 12/May/22  Updated: 06/Dec/22  Resolved: 13/May/22

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

Type: Bug Priority: Major - P3
Reporter: Rui Liu Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-62432 Ensure safe access to ShardingDDLCoor... Closed
Related
is related to SERVER-62432 Ensure safe access to ShardingDDLCoor... Closed
is related to SERVER-65500 Unprotected concurrent access to coor... Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Participants:
Linked BF Score: 137

 Description   

When we create a DDL coordinator we may run checkIfOptionsConflict on the existing coordinator while it's running, which might be in the point of updating the state document, for example here. This update may result in part of the original state doc's memory freed. However, the concurrent `checkIfOptionsConflict` may be still accessing this freed memory, hence causing a crash.

This problem might not be exposed to other DDL coordinators yet because `collModRequest` has more complicated internal structure like `std::vector<...>`, which we believe is being freed during the update, since the serialization code uses the reference of the vector instead of making a copy. That said, this seems to be generic sharding DDL coordinator problem that probably should be handled in a general way.



 Comments   
Comment by Rui Liu [ 13/May/22 ]

Sorry, seems this ticket is a duplicate of SERVER-62432, closing it.

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