You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug had two reasons - first (and primary) that we relied upon some order of objects' destruction, where default_stats_group was destroyed after all other objects, which used dynamic memory allocation. But nobody actually guarantees this, and on PPC bug happened. Mutex, used in AtomicCounter, was already destroyed at a moment, when it was attempted to be used in some destructor. Exception system_call_failed happened, and here we come to the second reason.
We can't (at least using this platform) throw exceptions from memory pool, when it's mutex is locked! Compiler needs some memory to create exception, it calls new for this - and in that new that same mutex is attempted to be entered once more. Deadlock and hang.
I fixed wrong destruction order making default_stats_group permanent pointer, i.e. it will never be destoryed, but will dye together with a process. Therefore I mark this particular bug as resolved, though we must decide what to do with exceptions in memory manager.