Crash at shutdown (global destructor order is undefined) #1832

1. 
   gavinandresen commented at 9:48 pm on September 18, 2012: contributor

   CDBEnv::Shutdown calls OutputDebugStringF if there is an error closing the database.

   The database environment is a global variable.

   OutputDebugStringF contains a static boost::mutex.

   C++ does not guarantee an order for the destruction of static/global objects, and I am getting a crash I assume because at shutdown (I’m testing handling of corrupt wallet files):

   the static mutexDebugLog is destroyed THEN the bitdb CDBEnv is destroyed, calling printf (OutputDebugStringF), which then crashes calling scoped_lock(mutexDebugLog)

2. 
   laanwj commented at 8:04 am on September 20, 2012: member

   Hm, this could be solved by making CDBEnv bitdb an explicitly constructed/destructed singleton instead of a static global. Explicitly created in Init() and destroyed in Shutdown().

   It would be more clear, too.

3. 
   gavinandresen commented at 2:39 pm on September 20, 2012: contributor

   But then we’ll run into the same issue again if we ever have other global or static objects that want to printf() during shutdown (and it is a nasty issue because it can work just fine for some people and not for others).

   Making the mutex a pointer initialized to NULL, creating it using ’new’ and then simply never deleting it is probably the best fix.

4. 
   laanwj commented at 2:49 pm on September 20, 2012: member

   Yes that would fix the instances of printf() in shutdown, but there could always be other dependencies between static objects’ destructors.

   I think it’d be better to not have non-trivial objects that rely on static construction / destruction, and do our own object lifetime management in a well-defined order. That seems to be pretty common in C++ coding guidelines.

   Or do both.

5. 
   Diapolo commented at 6:37 am on January 11, 2013: none

   @gavinandresen Wasn’t this also fixed?
6. 
   gavinandresen commented at 4:13 pm on January 11, 2013: contributor

   @Diapolo : yes, thanks for looking through the issues list, that’s a huge help! Closing.
7. gavinandresen closed this on Jan 11, 2013

   ---

8. 
   Diapolo commented at 4:42 pm on January 11, 2013: none

   I’ll keep an eye on the issues list, because it’s getting quite long recently ;).
9. MarcoFalke locked this on Sep 8, 2021

Contributors
gavinandresen laanwj Diapolo

Labels
Bug