[SERVER-69206] Coverity analysis defect 122738: Using a moved object Created: 26/Aug/22  Updated: 06/Nov/23  Resolved: 16/May/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0, 7.0.4

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: George Wangensteen
Resolution: Fixed Votes: 0
Labels: coverity, neweng, sdlc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Assigned Teams:
Service Arch
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.0
Sprint: Service Arch 2023-05-29
Participants:

 Description   

Using a moved object

Using a moved object may lead to an unexpected/undefined behavior. An object is used after it's moved.
/src/mongo/executor/connection_pool.cpp:523: USE_AFTER_MOVE 122738 "options" is moved (indicated by "std::move(options)").
/src/mongo/executor/connection_pool.cpp:525: USE_AFTER_MOVE 122738 "options" is used after it has been already moved.



 Comments   
Comment by Githook User [ 03/Nov/23 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-69206 Remove use-after-move on ConnectionPool::Options in ConnectionPool constructor.

(cherry picked from commit 256e1eada460330526f22fdf9bb4171c35f058a2)
Branch: v7.0
https://github.com/mongodb/mongo/commit/c55aadd71f364e963af08bfb685a5d6aa0a32237

Comment by George Wangensteen [ 16/May/23 ]

jason.chan@mongodb.com Do we want to backport this to 7.0 given the above? 

Comment by Githook User [ 16/May/23 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-69206 Remove use-after-move on ConnectionPool::Options in ConnectionPool constructor.
Branch: master
https://github.com/mongodb/mongo/commit/256e1eada460330526f22fdf9bb4171c35f058a2

Comment by George Wangensteen [ 15/May/23 ]

I do think this is only cosmetic. The ConnectionPool::Options struct's move-assignment operator is implicitly defined; according to cpp-reference, this means it should do " the move assignment operator performs full member-wise move assignment of the object's direct bases and immediate non-static members, in their declaration order, using built-in assignment for the scalars". The only thing accessed after the move is the (https://github.com/10gen/mongo/blob/8896b5ba5a84d1b6b63953b9009ca16eda69d3c6/src/mongo/executor/connection_pool.cpp#L559) is the egressTagCloserManager raw-pointer, which, as it is a pointer, is a scalar type that should have just been copied via built-in assignment during the move, per the above. So the pointer should still be valid in the moved-from object, in my understanding. 

(That said, it's a 1-character fix, so we should just do it anyway to avoid the confusion! But I'll take it out of 7.0 blocking). 

Comment by Eric Milkie [ 10/May/23 ]

Please confirm if this problem is only cosmetic – if so, take it out of 7.0 blocking status.

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