Changing LockedPageManager to use a managed instance

This ensures the allocator is ready no matter when it's needed (as
some STL implementations allocate in constructors -- i.e., MSVC's STL
in debug builds).

Using boost::call_once to guarantee thread-safe static initialization.

Adding some comments describing why the change was made.

Addressing deinitialization of the LockedPageManager object
by initializing it in a local static initializer and adding
an assert in the base's destructor.

1 files changed, 4 insertions, 4 deletions

diff --git a/src/crypter.h b/src/crypter.h
index 4134c1b49b..9826d63b76 100644
--- a/src/crypter.h
+++ b/src/crypter.h
@@ -88,16 +88,16 @@ public:
         // Try to keep the key data out of swap (and be a bit over-careful to keep the IV that we don't even use out of swap)
         // Note that this does nothing about suspend-to-disk (which will put all our key data on disk)
         // Note as well that at no point in this program is any attempt made to prevent stealing of keys by reading the memory of the running process.
-        LockedPageManager::instance.LockRange(&chKey[0], sizeof chKey);
-        LockedPageManager::instance.LockRange(&chIV[0], sizeof chIV);
+        LockedPageManager::Instance().LockRange(&chKey[0], sizeof chKey);
+        LockedPageManager::Instance().LockRange(&chIV[0], sizeof chIV);
     }
 
     ~CCrypter()
     {
         CleanKey();
 
-        LockedPageManager::instance.UnlockRange(&chKey[0], sizeof chKey);
-        LockedPageManager::instance.UnlockRange(&chIV[0], sizeof chIV);
+        LockedPageManager::Instance().UnlockRange(&chKey[0], sizeof chKey);
+        LockedPageManager::Instance().UnlockRange(&chIV[0], sizeof chIV);
     }
 };