Windows DLLs and TLS

[Rainer Schuetze]

On 10/8/2012 1:26 PM, Jakob Ovrum wrote:
> I have a bug in one of my programs that I find particularly hard to reduce.
>
> I am writing a Windows DLL plugin for the IRC chat client HexChat (aka
> XChat). Problem is, all TLS variables, regardless of type, appear to be
> initialized to complete rubbish values. Reading them does not cause an
> access violation or anything, but the initial values are garbage. I am
> initializing the runtime using the helpers found in core.sys.windows.dll
> [1].
>
> I wrote a dummy host application in C mimicking the loading behaviour of
> HexChat - the TLS variables are initialized correctly in this case, even
> though the DLL file is exactly the same.
>
> What is it that a host application can do to break the TLS of a D plugin
> it loads?
>
> [1] http://pastebin.com/rg9uUQMe
>


What OS are you running? Implicite TLS for dynamically loaded DLLs is 
not supported by XP or Sever 2003, so druntime contains a fix to 
simulate it. (The workaround has the drawback that the DLL cannot be 
unloaded anymore.)

I'm just speculating, maybe something goes wrong with the tls_index 
variable, reading TLS variables would then access data from another DLL.

Is your code doing callbacks into the host application in static 
initializers? With the XP workaround, the runtime initialization 
"impersonates" all threads that exist before loading the DLL, by 
switching the TLS-pointer array of the current thread, and that might be 
unexpected in a callback (but not doing this might produce even more 
unexpected results).