Details
Description
Occasionally mongorestore fails to start with the following call stack:
sh27974| 2014-03-14T15:46:07.210-0400 [journal] Fatal Assertion 16842
|
sh27974| 2014-03-14T15:46:07.210-0400 jstests/dur/data/empty.bson
|
sh27974| 2014-03-14T15:46:07.210-0400 going into namespace [test.empty]
|
sh27974| 2014-03-14T15:46:07.213-0400 [journal] 0x10068edeb 0x100648712 0x10063827e 0x1000a33cc 0x10010a5f2 0x1001d2502 0x1006c31f5 0x7fff8c9257a2 0x7fff8c9121e1
|
sh27974| 0 mongorestore 0x000000010068edeb mongo::printStackTrace(std::ostream&) 43
|
sh27974| 1 mongorestore 0x0000000100648712 mongo::logContext(char const*) 114
|
sh27974| 2 mongorestore 0x000000010063827e mongo::fassertFailed(int) 110
|
sh27974| 3 mongorestore 0x00000001000a33cc mongo::getGlobalAuthorizationManager() 28
|
sh27974| 4 mongorestore 0x000000010010a5f2 mongo::Client::initThread(char const*, mongo::AbstractMessagingPort*) 640
|
sh27974| 5 mongorestore 0x00000001001d2502 mongo::dur::durThread() 34
|
sh27974| 6 mongorestore 0x00000001006c31f5 thread_proxy 229
|
sh27974| 7 libsystem_c.dylib 0x00007fff8c9257a2 _pthread_start 327
|
sh27974| 8 libsystem_c.dylib 0x00007fff8c9121e1 thread_start 13
|
sh27974| 2014-03-14T15:46:07.214-0400 [journal]
|
sh27974|
|
sh27974| ***aborting after fassert() failure
|
sh27974|
|
This is because when the durThread starts it calls client::initThread, which calls getGlobalAuthorizationManager(), which has an fassert that the globalAuthorizationManager is set. In the run method of mongorestore, however, we briefly clear the globalAuthorizationManager to set it to a real implementation instead of a Mock. This leaves a small window where the globalAuthorizationManager is unset, which can trigger the fassert in getGlobalAuthorizationManager depending on the timing of the dur thread starting up.
Fix is to move the setting of the globalAuthorizationManager out of the Restore class' doRun method and into its constructor, which will run before the durThread is started.