Possible UB in DeleteLock() function #18824

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.

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

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

?