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

Debug assertion in Windows debug build, bad code in any build, due to incorrect lock usage

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.0.7
    • Affects Version/s: 2.0.7
    • Component/s: None
    • Labels:
    • Environment:
      Windows with journaling enabled
    • Windows

      The MemoryMappedFile::remapPrivateView() routine in Windows is using "RWLockRecursive::Exclusive lockMongoFiles(mmmutex)" to try to prevent other threads from accessing a memory-mapped file (the private view) while it is temporarily unmapped, but this code is called from "mongo::dur::_REMAPPRIVATEVIEW()" which has already taken out a shared lock on mmmutex. The release build does not complain about this, but it is wrong: the shared lock has set the recursion count to 1 and the exclusive lock sets it back to 0. If another thread tried to take out either a shared or an exclusive lock on mmmutex while we are in this state, it would think that it was the first locker and it would leak the previously allocated rwlock. The debug build, on the other hand, has a dassert() that tests the recursion count and aborts mongod.exe.

      We should probably take out an exclusive lock in _REMAPPRIVATEVIEW and (maybe, subject to code inspection) take out the exclusive lock in remapPrivateView. One way or another, we need to fix this incorrect usage of RWLockRecursive.

      >Debug.ListCallStack
       Index  Function
      --------------------------------------------------------------------------------
       1      msvcr100d.dll!_NMSG_WRITE()
       2      msvcr100d.dll!abort()
       3      mongod.exe!mongo::asserted(const char * msg=0x00000001406d8d40, const char * file=0x000000014067ee90, unsigned int line=0x00000162)
       4      mongod.exe!mongo::RWLockRecursive::Exclusive::Exclusive(mongo::RWLockRecursive& r={...})
      *5      mongod.exe!mongo::MemoryMappedFile::remapPrivateView(void * oldPrivateAddr=0x0000004001000000)
       6      mongod.exe!mongo::MongoMMF::remapThePrivateView()
       7      mongod.exe!mongo::dur::_REMAPPRIVATEVIEW()
       8      mongod.exe!mongo::dur::REMAPPRIVATEVIEW()
       9      mongod.exe!mongo::MongoMutex::_acquiredWriteLock()
       10     mongod.exe!mongo::MongoMutex::lock()
       11     mongod.exe!mongo::writelock::writelock(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > &ns="Alberto.Lerner")
       12     mongod.exe!mongo::receivedInsert(mongo::Message & m={...}, mongo::CurOp & op={...})
       13     mongod.exe!mongo::assembleResponse(mongo::Message & m={...}, mongo::DbResponse & dbresponse={...}, const mongo::HostAndPort &remote={...})
       14     mongod.exe!mongo::MyMessageHandler::process(mongo::Message &m={...}, mongo::AbstractMessagingPort * port=0x00000000005774f0, mongo::LastError * le=0x0000000000577ca0)
       15     mongod.exe!mongo::pms::threadRun(mongo::MessagingPort * inPort=0x00000000005774f0)
       16     mongod.exe!boost::_bi::list1<boost::_bi::value<mongo::MessagingPort * __ptr64> >::operator()<void (__cdecl*)(mongo::MessagingPort * __ptr64),boost::_bi::list0>(boost::_bi::type<void> __formal={...}, void (mongo::MessagingPort *)* & f=0x000000013fbf5195, boost::_bi::list0 & a={...}, boost::_bi::type<void> __formal={...})
       17     mongod.exe!boost::_bi::bind_t<void,void (__cdecl*)(mongo::MessagingPort * __ptr64),boost::_bi::list1<boost::_bi::value<mongo::MessagingPort * __ptr64> > >::operator()()
       18     mongod.exe!boost::detail::thread_data<boost::_bi::bind_t<void,void (__cdecl*)(mongo::MessagingPort * __ptr64),boost::_bi::list1<boost::_bi::value<mongo::MessagingPort * __ptr64> > > >::run()
       19     mongod.exe!boost::`anonymous namespace'::thread_start_function(void * param=0x0000000000203770)
       20     msvcr100d.dll!_beginthreadex()
       21     msvcr100d.dll!_beginthreadex()
       22     kernel32.dll!BaseThreadInitThunk()
       23     ntdll.dll!RtlUserThreadStart()
      

            Assignee:
            tad Tad Marshall
            Reporter:
            tad Tad Marshall
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: