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

Probably undefined behaviour

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor - P4
    • Resolution: Fixed
    • Affects Version/s: 1.9.0
    • Fix Version/s: 1.9.1
    • Component/s: Replication
    • Environment:
      N/A
    • Operating System:
      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

            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: