>The output certainly suggests something is calling TlsAlloc between the call
>made for destructor_key.value and the one for private_drbg, and that index is
>never freed. You always get 7 when allocating destructor_key.value because
>that >index was freed when you unloaded OpenSSL, and so it's the next
>available one when you load OpenSSL again.
>
>It may not be OpenSSL itself that's calling TlsAlloc and not releasing an
>index - it may be one of its dependencies.
>
>Have you duplicated this under a debugger, with a breakpoint on TlsAlloc? The
>earlier messages suggest that you may have, but it's not entirely clear from
>what you posted. You ought to be able to catch the offending call and get at
>>least a partial traceback.
>
>If you're having trouble tracing it, you could try adding this:
>
>{int i; for (i=8; i<private_drbg; i++) TlsSetValue(i, (LPVOID)-1);}
>
>right after the code that calls TlsAlloc for private_drbg, and seeing what
>blows up. Not entirely conventional, but it might be revealing.
After some further debugging, it appears there is an unknown TSAlloc called
which returned index 8. OpenSSL was allocating index 7, then the index 8 was
allocated somewhere outside the OpenSSL library, and finally OpenSSL allocated
indexes 9, 10, and 11. I was able to call TlsFree(8) in my DLLMain when my DLL
is unloaded and I didn't have any more issues. Obviously, that is not a fix
and I was further able to track down at least where the allocation was
happening. It is actually in a call to libxml2 and does not appear to be
related to OpenSSL. Now I just need to figure out why libxml2 is not freeing
it.
Thank you Matt and Michael for you help. :-)
