Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-6409

Fix failure due to assertion during rollback to stable

    • Type: Icon: Build Failure Build Failure
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • 5
    • Storage - Ra 2020-06-15, Storage - Ra 2020-06-29

      A multiversion test suite in MongoDB is failing during rollback to stable, with an assertion indicating that timestamps aren't in an expected state.

      The test case that triggered the failure is auto-generated in MongoDB, so I can't link to a particular test case.

      The first failure happened after this drop from WiredTiger - so a good starting point for diagnosing is probably reviewing the changes included there.

      The assertion is:

      [js_test:rollback_test-536d2-1591173474752-1] 2020-06-03T09:00:44.654+0000 d20031| | 2020-06-03T09:00:44.654+00:00 E  STORAGE  22435   [SignalHandler] "WiredTiger error","attr":{"error":0,"message":"[1591174844:654467][45275:0x7f47a189b700], file:_mdb_catalog.wt, txn rollback_to_stable: __rollback_row_ondisk_fixup_key, 246: (newer_hs_ts == WT_TS_NONE || hs_stop_ts <= newer_hs_ts || hs_start_ts == hs_stop_ts)"}
      

      Stacktrace:

      mongo::stack_trace_detail::(anonymous namespace)::printStackTraceImpl(mongo::stack_trace_detail::(anonymous namespace)::Options const&, mongo::StackTraceSink*)
      mongo::printStackTrace()
      mongo::(anonymous namespace)::abruptQuit(int)
      funlockfile
      gsignal
      abort
      __wt_abort
      __rollback_row_ondisk_fixup_key
      __rollback_abort_row_reconciled_page_internal
      __rollback_abort_newer_updates
      __rollback_to_stable_btree_apply
      __wt_rollback_to_stable
      __wt_txn_global_shutdown
      __conn_close
      mongo::WiredTigerKVEngine::cleanShutdown()
      mongo::shutdownGlobalStorageEngineCleanly(mongo::ServiceContext*)
      mongo::(anonymous namespace)::shutdownTask(mongo::ShutdownTaskArgs const&)
      mongo::(anonymous namespace)::runTasks(std::stack<mongo::unique_function<void (mongo::ShutdownTaskArgs const&)>, std::deque<mongo::unique_function<void (mongo::ShutdownTaskArgs const&)>, std::allocator<mongo::unique_function<void (mongo::ShutdownTaskArgs const&)> > > >, mongo::ShutdownTaskArgs const&)
      mongo::shutdown(mongo::ExitCode, mongo::ShutdownTaskArgs const&)
      mongo::exitCleanly(mongo::ExitCode)
      mongo::(anonymous namespace)::handleOneSignal(mongo::(anonymous namespace)::SignalWaitResult const&, mongo::(anonymous namespace)::LogRotationState*)
      mongo::(anonymous namespace)::signalProcessingThread(mongo::LogFileStatus)
      mongo::stdx::thread::thread<void (*)(mongo::LogFileStatus), mongo::LogFileStatus&, 0>(void (*)(mongo::LogFileStatus), mongo::LogFileStatus&)::{lambda()#1}::operator()()
      execute_native_thread_routine
      start_thread
      clone
      

            Assignee:
            haribabu.kommi@mongodb.com Haribabu Kommi
            Reporter:
            alexander.gorrod@mongodb.com Alexander Gorrod
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: