View mode: basic / threaded / horizontal-split · Log in · Help
October 08, 2012
Windows DLLs and TLS
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
October 08, 2012
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 11:44:28 UTC, 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

Did you already went through this howto?

http://dlang.org/dll.html
October 08, 2012
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 11:55:24 UTC, Paulo Pinto wrote:
> On Monday, 8 October 2012 at 11:44:28 UTC, 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
>
> Did you already went through this howto?
>
> http://dlang.org/dll.html

Of course. I've written many DLLs before, and again, TLS works in 
the exact same DLL when a different host program is used, hence 
why it's so difficult to reduce.

Besides, there's nothing relevant in that article.
October 08, 2012
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 12:00:00 UTC, Jakob Ovrum wrote:
> On Monday, 8 October 2012 at 11:55:24 UTC, Paulo Pinto wrote:
>> On Monday, 8 October 2012 at 11:44:28 UTC, 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
>>
>> Did you already went through this howto?
>>
>> http://dlang.org/dll.html
>
> Of course. I've written many DLLs before, and again, TLS works 
> in the exact same DLL when a different host program is used, 
> hence why it's so difficult to reduce.
>
> Besides, there's nothing relevant in that article.

Sorry, just thought it might be helpful.
October 08, 2012
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 15:52:12 UTC, Paulo Pinto wrote:
> Sorry, just thought it might be helpful.

No, I'm sorry, I shouldn't have replied in the tone that I did.

I truly appreciate the help.
October 08, 2012
Re: Windows DLLs and TLS
On Mon, 08 Oct 2012 12:26:29 +0100, Jakob Ovrum <jakobovrum@gmail.com>  
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

Could XChat be loading your dll using:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

and the flag DONT_RESOLVE_DLL_REFERENCES, or similar.

To debug, I would write a debug file using *C* IO functions from DllMain,  
check it loads/runs/outputs to the file from your dummy C host  
application, then try again with XChat and see what you get.

You could also alter the dummy C host application to call LoadLibraryEx  
and pass DONT_RESOLVE_DLL_REFERENCES and see what happens.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
October 08, 2012
Re: Windows DLLs and TLS
It is also (apparently) possible to load a DLL without using LoadLibrary:
http://www.codeproject.com/Tips/430684/Loading-Win32-DLLs-manually-without-LoadLibrary

Lets hope XChat is not doing anything quite that crazy..

R
October 08, 2012
Re: Windows DLLs and TLS
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).
October 08, 2012
Re: Windows DLLs and TLS
08.10.2012 15:26, Jakob Ovrum пишет:
> 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 do you use? This problem should be related to Windows XP/Server 
2003.

Does you dummy host application in C use implicit TLS?

Do C and D DLLs attached to this post behave differently for you 
regarding to TLS initialisation (load and call `getTLSIndex` and 
`getTLSVarValue`)?

I'll try to help but I need full test suit to see where is the 
difference between C and D DLLs.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
October 08, 2012
[OT] Re: Windows DLLs and TLS
08.10.2012 21:47, Rainer Schuetze пишет:
> 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).

Here you are! Just want to mention that I'm currently managed to publish 
my (continuation of your) TLS fix I did half a year before. It will 
finally solve this XP/Sever 2003 problem. It is available here but isn't 
finished now (fill be in few days):
https://github.com/denis-sh/hooking/tree/master/tlsfixer

I hope you aren't against it is based on your work?


-- 
Денис В. Шеломовский
Denis V. Shelomovskij
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home