Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-3335

Probably undefined behaviour

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Minor - P4
    • Resolution: Fixed
    • 1.9.0
    • 1.9.1
    • Replication
    • N/A
    • ALL

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

      Attachments

        Activity

          People

            eliot Eliot Horowitz (Inactive)
            matiu Matthew Sherborne
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: