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

OpMsg passed to ServiceEntryPoint::handleRequest() in AsyncWorkScheduler::scheduleRemoteCommand should outlive CurOp

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.10
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • Hide

      To reproduce, apply the following patch and run the sharding_csrs_continuous_config_stepdown suite in Evergreen against Enterprise RHEL 6.2. The invariant added to builder.h will trigger when encountered.

      diff --git a/etc/evergreen.yml b/etc/evergreen.yml
      index a26137de34..7a8bbbbb6b 100644
      --- a/etc/evergreen.yml
      +++ b/etc/evergreen.yml
      @@ -6227,7 +6227,7 @@ tasks:
         - func: "do setup"
         - func: "run tests"
           vars:
      -      resmoke_args: --suites=sharding_continuous_config_stepdown --storageEngine=wiredTiger
      +      resmoke_args: --repeat=10 --suites=sharding_continuous_config_stepdown --storageEngine=wiredTiger jstests/sharding/txn_commit_coordination_is_robust_to_killop.js
       
       - name: sharding_csrs_continuous_config_stepdown_gen
         commands:
      @@ -6236,7 +6236,7 @@ tasks:
             task: sharding_csrs_continuous_config_stepdown
             suite: sharding_continuous_config_stepdown
             use_large_distro: "true"
      -      resmoke_args: --storageEngine=wiredTiger
      +      resmoke_args: --storageEngine=wiredTiger --repeat=10 jstests/sharding/txn_commit_coordination_is_robust_to_killop.js
             fallback_num_sub_suites: 22
       
       - <<: *task_template
      diff --git a/src/mongo/bson/util/builder.h b/src/mongo/bson/util/builder.h
      index b316fee068..c2b25de3c4 100644
      --- a/src/mongo/bson/util/builder.h
      +++ b/src/mongo/bson/util/builder.h
      @@ -346,6 +346,7 @@ private:
               if (minSize > BufferMaxSize) {
                   std::stringstream ss;
                   ss << "BufBuilder attempted to grow() to " << minSize << " bytes, past the 64MB limit.";
      +            invariant(0);
                   msgasserted(13548, ss.str().c_str());
               }
       
      
      

       

      Show
      To reproduce, apply the following patch and run the sharding_csrs_continuous_config_stepdown suite in Evergreen against Enterprise RHEL 6.2. The invariant added to builder.h will trigger when encountered. diff --git a/etc/evergreen.yml b/etc/evergreen.yml index a26137de34..7a8bbbbb6b 100644 --- a/etc/evergreen.yml +++ b/etc/evergreen.yml @@ -6227,7 +6227,7 @@ tasks: - func: "do setup" - func: "run tests" vars: - resmoke_args: --suites=sharding_continuous_config_stepdown --storageEngine=wiredTiger + resmoke_args: --repeat=10 --suites=sharding_continuous_config_stepdown --storageEngine=wiredTiger jstests/sharding/txn_commit_coordination_is_robust_to_killop.js - name: sharding_csrs_continuous_config_stepdown_gen commands: @@ -6236,7 +6236,7 @@ tasks: task: sharding_csrs_continuous_config_stepdown suite: sharding_continuous_config_stepdown use_large_distro: "true" - resmoke_args: --storageEngine=wiredTiger + resmoke_args: --storageEngine=wiredTiger --repeat=10 jstests/sharding/txn_commit_coordination_is_robust_to_killop.js fallback_num_sub_suites: 22 - <<: *task_template diff --git a/src/mongo/bson/util/builder.h b/src/mongo/bson/util/builder.h index b316fee068..c2b25de3c4 100644 --- a/src/mongo/bson/util/builder.h +++ b/src/mongo/bson/util/builder.h @@ -346,6 +346,7 @@ private: if (minSize > BufferMaxSize) { std::stringstream ss; ss << "BufBuilder attempted to grow() to " << minSize << " bytes, past the 64MB limit."; + invariant(0); msgasserted(13548, ss.str().c_str()); }  
    • Sharding 2019-02-25, Sharding 2019-03-25, Sharding 2019-04-08
    • 18
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      In AsyncWorkScheduler::scheduleRemoteCommand(), we create an OpMsg object and pass to ServiceEntryPoint::handleRequest() to execute. This OpMsg object is torn down after we return the response status to the caller. This leaves us with a CurOp::_opDescription field that points to an unowned BSONObj that no longer exists. This object is unowned because copying is expensive and we expect that any OpMsg passed to ServiceEntryPoint::handleRequest() will outlive the client's CurOp object.

       

       

            Assignee:
            kaloian.manassiev@mongodb.com Kaloian Manassiev
            Reporter:
            james.wahlin@mongodb.com James Wahlin
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:
              None
              None
              None
              None