Workaround for thread local storage destruction order

The current OPENSSL_thread_stop() mechanism uses thread local storage
to store cleanup handlers for the various threads. When a thread exits the
destructor for the thread local storage gets called and we can call the
various handlers. The handlers assume that they can still access the
thread local storage for that particular part of the code - but this relies
on the OPENSSL_thread_stop() thread local storage being destroyed first.
If happens in a different order then glibc seems to NULL out thread local
storage that hasn't been explicitly destroyed causing a memory leak.

glibc seems to call the destructors in the same order that the keys were
created, so we workaround this by always ensuring that the
OPENSSL_thread_stop() key is always created first. This is only a
workaround because it assumes a particular implementation in glibc. We need
a better solution.

We also revert an earlier change in test/threadstest.h. This was only
necessary because of this problem and masked the real issue.

crypto/context.c

@@ -374,6 +374,9 @@ static int default_context_inited = 0;
 
 DEFINE_RUN_ONCE_STATIC(default_context_do_init)
 {
+    if (!ossl_init_thread())
+        goto err;
+
     if (!CRYPTO_THREAD_init_local(&default_context_thread_local, NULL))
         goto err;
 

crypto/initthread.c

@@ -201,9 +201,11 @@ static void init_thread_destructor(void *hands)
 
 int ossl_init_thread(void)
 {
-    if (!CRYPTO_THREAD_init_local(&destructor_key.value,
-                                  init_thread_destructor))
-        return 0;
+    if (destructor_key.sane == -1) {
+        if (!CRYPTO_THREAD_init_local(&destructor_key.value,
+                                    init_thread_destructor))
+            return 0;
+    }
 
     return 1;
 }

test/threadstest.h

@@ -65,7 +65,6 @@ static void *thread_run(void *arg)
     *(void **) (&f) = arg;
 
     f();
-    OPENSSL_thread_stop();
     return NULL;
 }