[SERVER-37632] CollectionClonerRenamedBeforeStartTest should not reference client object that has already been destroyed Created: 15/Oct/18  Updated: 06/Dec/22  Resolved: 22/Jan/19

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

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-38072 CollectionClonerTest references memor... Closed
Related
is related to SERVER-38072 CollectionClonerTest references memor... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:
Linked BF Score: 13

 Description   

In the CollectionClonerRenamedBeforeStartTest tests, we will initially call the setUpVerifyCollectionWasDroppedTest method. This method will first set an error code to return for the initial collection cloner query. Later on, it then resumes the query which was initially paused. This just lets the query inside the collection cloner continue (and, in this case, return an error). If runQuery receives an error on its initial request, it will then try to start up the collection drop verifier. We start up the verifier but don't wait on it to finish, so we will then just return. This causes us to execute this ON_BLOCK_EXIT block and destroy the client. This is a problem, since this client object is the same one we hold a reference to in the test fixture. If we subsequently try to call waitForResumedQuery on that client object, it will have been destroyed by that point i.e. we are referencing freed memory.



 Comments   
Comment by Matthew Russotto [ 22/Jan/19 ]

Yes, closing as duplicate.

Comment by William Schultz (Inactive) [ 22/Jan/19 ]

matthew.russotto Was this fixed by SERVER-38072?

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