Two commits, two fixes.
First is an obscure infinite loop on Windows (and possible crash-at-shutdown). Most of the difference in that commit are just an indentation change from switching from LOCK(cs_...) to using mutexDebugLock.
Second is a fix for an obscure crash-at-shutdown on all platforms.
Tested by running without -debug, with -debug and with -debug=net -debug=mempool.
Running -printtodebugger -debug (or -debug=lock),
compiled with -DDEBUG_LOCKORDER would infinite loop
on Windows because every critical section lock/unlock
triggers a LogPrint.
Solution is to use the raw boost mutex instead of a CCriticalSection.
This prevents crashes at shutdown where a global destructor
calls LogPrint(category...) after mapMultiArgs has been
deleted.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/0b238b278686f8e0c6609b7c9360d36c3198105c for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
304 | @@ -299,27 +305,24 @@ int LogPrint(const char* category, const char* pszFormat, ...)
305 | #ifdef WIN32
306 | if (fPrintToDebugger)
BTW I strongly doubt that anyone is using "print to debugger". It's a strange, obscure, WIN32-only thing. Maybe it'd be better to get rid of it.
Agree on getting rid of it.
256 | + if (ptrCategory.get() == NULL) 257 | { 258 | - // Category was not found (not supplied via -debug=<category>) 259 | - if (find(categories.begin(), categories.end(), string(category)) == categories.end()) 260 | - return 0; 261 | + const vector<string>& categories = mapMultiArgs["-debug"];
ACK -- we must make sure though that no one will ever call LogPrint before mapMultiArgs has its final state, to avoid different threads ending up with different values. Neither ReadConfigFile nor ParseParameters calls LogPrint (and neither does any of the supporting code, it appears) so right now it is safe. In any case this is better than a crash.