[SERVER-53837] Race of OplogFetcher access in TenantMigrationRecipientServiceTest.OplogApplierFails Created: 15/Jan/21  Updated: 29/Oct/23  Resolved: 22/Jan/21

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

Type: Bug Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Lingzhi Deng
Resolution: Fixed Votes: 0
Labels: pm-1791_other_required
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2021-01-25
Participants:
Linked BF Score: 0

 Description   

In this OplogApplierFails test, we use an OplogFetcherMock to feed an oplog entry that doesn't belong to the tenant to test that TenantOplogApplier fails the migration. When failing the migration, the main chain would call _cleanupOnDataSyncCompletion which would clean up and free the _donorOplogFetcher. But this could race with the test thread that calls oplogFetcher->receiveBatch which could end up accessing freed memory if the _donorOplogFetcher object is freed before the receiveBatch returns.

To fix this, we could use the hangBeforeTaskCompletion failpoint to hang the main chain before _cleanupOnDataSyncCompletion is run.



 Comments   
Comment by Githook User [ 22/Jan/21 ]

Author:

{'name': 'Sergey Galtsev', 'email': 'sergey.galtsev@mongodb.com', 'username': 'brushless-glitch'}

Message: master: SERVER-53837: Fix race of OplogFetcher access in TenantMigrationRecipientServiceTest.OplogApplierFails
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/b2d1ddb3112df766789e34e25a6d3ad0bfa29dad

Comment by Githook User [ 22/Jan/21 ]

Author:

{'name': 'Lingzhi Deng', 'email': 'lingzhi.deng@mongodb.com', 'username': 'ldennis'}

Message: SERVER-53837: Fix race of OplogFetcher access in TenantMigrationRecipientServiceTest.OplogApplierFails
Branch: master
https://github.com/mongodb/mongo/commit/02b4940e6fd5b0ede47da618721b9a70eb5f603a

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