[SERVER-6252] Debug assertion in Windows debug build, bad code in any build, due to incorrect lock usage Created: 29/Jun/12  Updated: 11/Jul/16  Resolved: 27/Jul/12

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 2.0.7
Fix Version/s: 2.0.7

Type: Bug Priority: Major - P3
Reporter: Tad Marshall Assignee: Tad Marshall
Resolution: Done Votes: 0
Labels: Windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows with journaling enabled


Issue Links:
Depends
Operating System: Windows
Participants:

 Description   

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()



 Comments   
Comment by Asya Kamsky [ 20/Oct/14 ]

Paul,

I believe this may be happening due to use of Windows32.

As noted on the MongoDB downloads page
32-bit builds are limited to around 2GB of data. In general you should use the 64 bit builds. The 32 bit binaries are ok for replica set arbiters and mongos' but not for production mongod's.

Asya

Comment by Tad Marshall [ 27/Jul/12 ]

Fixed by Eric in commit c88805a6f6447458290719703887fb736692359e .

Comment by Tad Marshall [ 29/Jun/12 ]

Passing to Andy to decide how best to fix this.

Generated at Thu Feb 08 03:11:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.