[SERVER-3335] Probably undefined behaviour Created: 25/Jun/11  Updated: 12/Jul/16  Resolved: 26/Jun/11

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

Type: Bug Priority: Minor - P4
Reporter: Matthew Sherborne Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: replication, threads
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Operating System: ALL
Participants:

 Description   

In the latest git pull I noticed the following:

db/repl.h:89 - unique_ptr<ThreadPool> tp;
ReplSource class has an auto_ptr to ThreadPool (which is a non-copyable)

db/repl.c:353 - v.push_back( shared_ptr< ReplSource >( new ReplSource( s ) ) );
Does a cope of one ReplSource to another.

As there is no copy contructor for ReplSource .. if 's' has a 'tp' assigned, something bad will happen.

Most likely the new ReplSource will get the first ReplSource's thread pool, and the first one's will become null.

Probably the designed behaviour would be to have the new ReplSource build its own thread pool, and not steal 's's one.

I guess the fix would be to give ReplSource a copy constructor, that handles auto_ptr<ThreadPool> correctly (by leaving the original, and creating a new one for the new copy).



 Comments   
Comment by auto [ 26/Jun/11 ]

Author:

{u'login': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}

Message: safer access SERVER-3335
Branch: master
https://github.com/mongodb/mongo/commit/5cbe8caea270c855fa2698f9e73da07a2d6f5a29

Generated at Thu Feb 08 03:02:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.