[SERVER-48592] Fix use-after-free ClockSourceMock bug in transaction_coordinator_test Created: 04/Jun/20  Updated: 22/Aug/20  Resolved: 22/Aug/20

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

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Pierlauro Sciarelli
Resolution: Duplicate Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-48654 TransactionCoordinatorMetricsTest sho... Closed
Operating System: ALL
Sprint: Sharding 2020-08-24
Participants:
Linked BF Score: 0

 Description   

In transaction_coordinator_test, a ClockSourceMock gets associated to a service context that is already used by the WaitForMajorityService.

As a result, it is potentially possible that a pointer to the original service context's ClockSource is used when waiting on an operation context instantiated before the ClockSourceMock.

Check BF-17382 for additional details.



 Comments   
Comment by Max Hirschhorn [ 22/Aug/20 ]

Reopening this ticket to close it as a duplicate of SERVER-48654.

Comment by Pierlauro Sciarelli [ 21/Aug/20 ]

The bug inĀ TransactionCoordinatorMetricsTest::setup() was caused by TransactionCoordinatorTestBase::setUp() being called before setting the clock source, resulting in the TransactionCoordinatorTestFixture::setup() initializing the WaitForMajorityService with an incorrect clock.

Looking at the current TransactionCoordinatorMetricsTest::setup(), the order has already been correctly switched as the correct clock is initialized before calling TransactionCoordinatorTestBase::setUp().

Closing as gone away.

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