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

Attempting to create an existing sharded collection causes mongos to crash when using a logical session id

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.5.13
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      python buildscripts/resmoke.py --suites=no_server repro_server30936.js
      

      server30936.js

      (function() {
          "use strict";
       
          const st = new ShardingTest({mongos: 1, config: 1, shards: 1});
       
          const db = st.s.getDB("test");
          assert.commandWorked(db.adminCommand({enableSharding: db.getName()}));
          assert.commandWorked(db.adminCommand({shardCollection: db.mycoll.getFullName(), key: {a: 1}}));
       
          const dbWithSession = db.getMongo().startSession().getDatabase("test");
          assert.commandFailedWithCode(dbWithSession.runCommand({create: db.mycoll.getName()}),
                                       ErrorCodes.NamespaceExists);
       
          st.stop();
      })();
      

      Show
      python buildscripts/resmoke.py --suites=no_server repro_server30936.js server30936.js ( function () { "use strict" ;   const st = new ShardingTest({mongos: 1, config: 1, shards: 1});   const db = st.s.getDB( "test" ); assert.commandWorked(db.adminCommand({enableSharding: db.getName()})); assert.commandWorked(db.adminCommand({shardCollection: db.mycoll.getFullName(), key: {a: 1}}));   const dbWithSession = db.getMongo().startSession().getDatabase( "test" ); assert.commandFailedWithCode(dbWithSession.runCommand({create: db.mycoll.getName()}), ErrorCodes.NamespaceExists);   st.stop(); })();
    • Linked BF Score:
      0

      Description

      The OperationContext::setLogicalSessionId() function and its invariant(!_lsid) were introduced as part of the changes from 8fe4426 in SERVER-29852, and exist only on the master branch. This issue therefore doesn't affect the 3.2 or 3.4 branches.

      #0  0x00007fd0824ce1fb in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
      #1  0x00007fd0842af5d3 in mongo::breakpoint () at src/mongo/util/debugger.cpp:75
      #2  0x00007fd08367e188 in mongo::invariantFailed (expr=expr@entry=0x7fd08439f73b "!_lsid", file=file@entry=0x7fd08437b820 "src/mongo/db/operation_context.cpp", line=line@entry=359) at src/mongo/util/assert_util.cpp:128
      #3  0x00007fd08407b6d8 in mongo::OperationContext::setLogicalSessionId (this=this@entry=0x7fd08609ea00, lsid=...) at src/mongo/db/operation_context.cpp:359
      #4  0x00007fd083b1dd76 in mongo::initializeOperationSessionInfo (opCtx=opCtx@entry=0x7fd08609ea00, requestBody=unowned BSONObj 74 bytes @ 0x7fd086099a9d = {...}, requiresAuth=<optimized out>) at src/mongo/db/initialize_operation_session_info.cpp:51
      #5  0x00007fd0837b253a in mongo::(anonymous namespace)::runAgainstRegistered (anObjBuilder=..., request=..., opCtx=0x7fd08609ea00) at src/mongo/s/commands/strategy.cpp:262
      #6  mongo::(anonymous namespace)::runCommand(mongo::OperationContext *, const mongo::OpMsgRequest &, <unknown type in /home/maxh/debugging/mongo/mongos, CU 0x0, DIE 0x111b38>) (opCtx=0x7fd08609ea00, request=..., builder=builder@entry=<unknown type in /home/maxh/debugging/mongo/mongos, CU 0x0, DIE 0x111b38>, this=<optimized out>) at src/mongo/s/commands/strategy.cpp:284
      #7  0x00007fd0837b5244 in mongo::Strategy::<lambda()>::operator()(void) const (__closure=__closure@entry=0x7fd0831fc530) at src/mongo/s/commands/strategy.cpp:437
      #8  0x00007fd0837b5b69 in mongo::Strategy::clientCommand (opCtx=opCtx@entry=0x7fd08609ea00, m=...) at src/mongo/s/commands/strategy.cpp:447
      #9  0x00007fd0836c8f61 in mongo::ServiceEntryPointMongos::handleRequest (this=<optimized out>, opCtx=0x7fd08609ea00, message=...) at src/mongo/s/service_entry_point_mongos.cpp:92
      #10 0x00007fd0836e28d0 in mongo::ServiceStateMachine::_processMessage (this=this@entry=0x7fd0860a60f0, guard=...) at src/mongo/transport/service_state_machine.cpp:317
      #11 0x00007fd0836df8c5 in mongo::ServiceStateMachine::_runNextInGuard (this=this@entry=0x7fd0860a60f0, guard=...) at src/mongo/transport/service_state_machine.cpp:407
      #12 0x00007fd0836e19f7 in mongo::ServiceStateMachine::runNext (this=0x7fd0860a60f0) at src/mongo/transport/service_state_machine.cpp:373
      #13 0x00007fd0836dd1e1 in mongo::ServiceEntryPointImpl::<lambda()>::operator() (__closure=0x7fd085f9fa00) at src/mongo/transport/service_entry_point_impl.cpp:89
      #14 std::_Function_handler<void(), mongo::ServiceEntryPointImpl::startSession(mongo::transport::SessionHandle)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...) at /opt/mongodbtoolchain/v2/include/c++/5.4.0/functional:1871
      #15 0x00007fd084082334 in std::function<void ()>::operator()() const (this=<optimized out>) at /opt/mongodbtoolchain/v2/include/c++/5.4.0/functional:2267
      #16 mongo::(anonymous namespace)::runFunc (ctx=0x7fd085f9f9c0) at src/mongo/transport/service_entry_point_utils.cpp:55
      #17 0x00007fd0824c6184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
      #18 0x00007fd0821f2ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              kaloian.manassiev Kaloian Manassiev
              Reporter:
              max.hirschhorn Max Hirschhorn
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: