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).