Possible UB in DeleteLock() function #18824

1. 
   hebasto commented at 7:28 am on April 30, 2020: member

   Since #15233 has been merged, the lockdata becomes a static local variable with a well-defined initialization order: https://github.com/bitcoin/bitcoin/blob/36c0abd8f61ba859d53b1e59014720282c97c143/src/sync.cpp#L93-L96

   Its destructor ~LockData() is called at program exit.

   At the same time, “if a function-local … static object was destroyed and then that function is called from the destructor…, the behavior is undefined.”

   It seems possible that at program exit the lockdata object is destroyed before a global RecursiveMutex destructor calls DeleteLock(), which in turn calls GetLockData() with UB.

2. 
   MarcoFalke commented at 11:33 am on April 30, 2020: member

   Is the de-initialization order for globals initialized on first use the inverse order of how they were initialized?
3. 
   hebasto commented at 6:28 pm on April 30, 2020: member

   Is the de-initialization order for globals initialized on first use the inverse order of how they were initialized?

   Yes, it is. But how it prevents from the following sequences:

   • on startup
     • global RecursiveMutex some_mutex initialization
     • …
     • LOCK(some_mutex) -> GetLockData() -> COFU initialization of lockdata
     • …
   • at exit
     • …
     • destruction of lockdata
     • …
     • some_mutex desctruction -> DeleteLock() -> GetLockData() -> UB

   ?

4. MarcoFalke closed this on May 26, 2020

   ---

5. sidhujag referenced this in commit c8b5293c9b on May 27, 2020
6. MarcoFalke locked this on Feb 15, 2022

Contributors
hebasto MarcoFalke