Fix Singleton/ThreadLocal destruction order crashes in buck dev builds

Summary: This adds a folly::Singleton->folly::ThreadLocal dependency to make sure folly::ThreadLocal is always loaded first. Otherwise PthreadKeyUnregister singleton is created after folly::Singleton storage, even though it has higher priority.

Reviewed By: andrewjcg

Differential Revision: D2931170

fb-gh-sync-id: 36392d76e98201f2b4416b4bbef451d6c0e8c69d
shipit-source-id: 36392d76e98201f2b4416b4bbef451d6c0e8c69d

diff --git a/folly/Singleton.cpp b/folly/Singleton.cpp
index 66321bfdc1e47c4e9a37285b405d8b0bb39cef51..1cf9c4d9efa673da6935a1f490a8002312188436 100644 (file)
--- a/folly/Singleton.cpp
+++ b/folly/Singleton.cpp
@@ -213,6 +213,10 @@ void SingletonVault::reenableInstances() {
 }
 
 void SingletonVault::scheduleDestroyInstances() {
+  // Add a dependency on folly::ThreadLocal to make sure all its static
+  // singletons are initalized first.
+  threadlocal_detail::StaticMeta<void>::instance();
+
   class SingletonVaultDestructor {
    public:
     ~SingletonVaultDestructor() {