www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows DLLs and TLS

reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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
Oct 08 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Oct 08 2012
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Oct 08 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Oct 08 2012
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Oct 08 2012
prev sibling next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
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/
Oct 08 2012
next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
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
Oct 08 2012
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 8 October 2012 at 17:20:03 UTC, Regan Heath wrote:
 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
Upon loading the application, which is when plugins are loaded, DLL_PROCESS_ATTACH is invoked once. Subsequently, DLL_THREAD_ATTACH is invoked 4 times. Then after about a second, still during startup, DLL_THREAD_DETACH is invoked twice. DLL_PROCESS_DETACH is then invoked once when closing the application. XChat uses gmodule - part of glib - to load plugins. I looked at gmodule's Windows implementation, and it uses LoadLibraryW. Despite finding all this, I still tried modifying the dummy host to use LoadLibraryEx out of curiosity. An access violation occurs in some druntime exception handling code as soon as I call into the plugin's init function.
Oct 08 2012
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Mon, 08 Oct 2012 19:32:40 +0100, Jakob Ovrum <jakobovrum gmail.com>  
wrote:
 XChat uses gmodule - part of glib - to load plugins. I looked at  
 gmodule's Windows implementation, and it uses LoadLibraryW.
Does your dummy C host application also use gmodule to load the dll.. that might be a useful experiment perhaps. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 09 2012
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 October 2012 at 10:21:58 UTC, Regan Heath wrote:
 On Mon, 08 Oct 2012 19:32:40 +0100, Jakob Ovrum 
 <jakobovrum gmail.com> wrote:
 XChat uses gmodule - part of glib - to load plugins. I looked 
 at gmodule's Windows implementation, and it uses LoadLibraryW.
Does your dummy C host application also use gmodule to load the dll.. that might be a useful experiment perhaps. R
I tried this, and the results are illuminating. I added gmodule support to the C host, enabling switching between using gmodule and direct WinAPI at the switch of a preprocessor define. When the WinAPI is used directly, they get their correct initializers like before (I included some variables with explicit initializers too, like void* test3 = cast(void*)1). When gmodule is used, the test TLS variables contain garbage! The garbage values are different every time the program runs. I'll look closer at what gmodule is doing.
Oct 09 2012
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 October 2012 at 10:21:58 UTC, Regan Heath wrote:
 Does your dummy C host application also use gmodule to load the 
 dll.. that might be a useful experiment perhaps.

 R
The problem has now been reduced to these two palatable programs. bug.dll ----------------------- import core.stdc.stdio; string[] test; void* test2; void* test3 = cast(void*)1; void* test4; // This is here so that the next function // becomes exported as "init" instead of "_init". // The first exported symbol gets a preceeding underscore // (Windows "system" convention) when using DMD/OPTLINK // for some reason. export extern(C) void _systemconvdummy() {} export extern(C) void init() { printf("test = %p:%d\n", test.ptr, test.length); printf("test2 = %p, test3 = %p, test4 = %p\n", test2, test3, test4); } ----------------------- DllMain is as posted before. It can initialize the runtime or be empty - the result is the same. rundll.exe ----------------------- #include <stdio.h> // Comment this out to use the WinAPI directly. #define USE_GLIB #ifdef USE_GLIB #include <gmodule.h> #else #include <Windows.h> #endif int main() { void (*init)(); #ifdef USE_GLIB GModule* handle = g_module_open("bug.dll", 0); #else HMODULE handle = LoadLibrary(L"bug.dll"); #endif printf("handle: %p\n", handle); #ifdef USE_GLIB g_module_symbol(handle, "init", &init); #else init = (void(*)())GetProcAddress(handle, "init"); #endif printf("init: %p\n", init); init(); return 0; } ----------------------- The glib headers and binaries all come from the GTK+ distribution [1]. I'll try reducing it further by not using gmodule to see exactly what the problem is, but it would be awesome if someone could try to reproduce this on their machines. [1] http://www.gtk.org/download/win32.php
Oct 09 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/9/12, Jakob Ovrum <jakobovrum gmail.com> wrote:
 The problem has now been reduced to these two palatable programs.
I get garbage values via LoadLibrary on both XP and Win7 (both x32). I haven't tried glib's version but I don't think it does anything differently. See _g_module_open and _g_module_symbol: http://www.koders.com/c/fidFBB7F65EF7D9F5843153A8CCFE31696E66DED44A.aspx
Oct 09 2012
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 October 2012 at 14:09:52 UTC, Andrej Mitrovic wrote:
 On 10/9/12, Jakob Ovrum <jakobovrum gmail.com> wrote:
 The problem has now been reduced to these two palatable 
 programs.
I get garbage values via LoadLibrary on both XP and Win7 (both x32). I haven't tried glib's version but I don't think it does anything differently. See _g_module_open and _g_module_symbol: http://www.koders.com/c/fidFBB7F65EF7D9F5843153A8CCFE31696E66DED44A.aspx
Thanks a lot for testing. Does it make a difference with and without the canonical DllMain [1]? Yeah, the reason I didn't bother trying gmodule at first was because of the seemingly trivial implementations those two functions. However, what you are looking at is an outdated version. The GTK+ distribution uses a more recent version that looks like this [2]. The only notable difference as far as I can tell is that it has Unicode support for _g_module_open. [1] http://pastebin.com/rg9uUQMe [2] http://pastebin.com/BirJM1uz
Oct 09 2012
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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).
Oct 08 2012
next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Oct 08 2012
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/8/2012 8:13 PM, Denis Shelomovskij wrote:
 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
Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool.
 I hope you aren't against it is based on your work?
Sure, no problem. It's boost licensed, isn't it? ;-)
Oct 08 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
09.10.2012 0:51, Rainer Schuetze пишет:
 On 10/8/2012 8:13 PM, Denis Shelomovskij wrote:
 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
Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool.
Unloading is fixed. I can't remember any problems with DLL_THREAD_ATTACH (but it was half year ago so I can miss something I did that time), can you concretize the problem? And it isn't related to D and D runtime (D is just an implementation language). It is assumed to fix everything launched on the system without administrator rights requirement (for office workers).
 I hope you aren't against it is based on your work?
Sure, no problem. It's boost licensed, isn't it? ;-)
Yes it is. But thanks anyway. -- Денис В. Шеломовский Denis V. Shelomovskij
Oct 09 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/9/2012 6:59 PM, Denis Shelomovskij wrote:
 09.10.2012 0:51, Rainer Schuetze пишет:
 On 10/8/2012 8:13 PM, Denis Shelomovskij wrote:
 08.10.2012 21:47, Rainer Schuetze пишет:
 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
Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool.
Unloading is fixed. I can't remember any problems with DLL_THREAD_ATTACH (but it was half year ago so I can miss something I did that time), can you concretize the problem?
What I meant is the "impersonation" of existing threads from the thread that executes DLL_PROCESS_ATTACH to run the thread-local static constructors. Even though the TLS pointers are switched, they are still executed in the context of the current thread. Looking it up again, this is not an XP problem, those threads don't get a DLL_THREAD_ATTACH callback on newer systems aswell. So I guess we will have to live with possible issues, but you are supposed to not really do a lot in DllMain anyway.
Oct 09 2012
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 8 October 2012 at 18:05:31 UTC, Rainer Schuetze wrote:
 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).
I'm running Windows 7, and I'm not using any static initializers either :(
Oct 08 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
08.10.2012 22:35, Jakob Ovrum пишет:
 On Monday, 8 October 2012 at 18:05:31 UTC, Rainer Schuetze wrote:
 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).
I'm running Windows 7, and I'm not using any static initializers either :(
As I said, give us a runnable failing test suite. As you are running Windows 7 the only reason I see is this nasty trap: http://d.puremagic.com/issues/show_bug.cgi?id=8130 Are you aware of it? -- Денис В. Шеломовский Denis V. Shelomovskij
Oct 08 2012
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij 
wrote:
 As I said, give us a runnable failing test suite.
I am working on it, but as I said, it's proving very difficult to replicate outside the XChat environment. I'll try to produce a reduced plugin though.
 As you are running Windows 7 the only reason I see is this 
 nasty trap:
 http://d.puremagic.com/issues/show_bug.cgi?id=8130

 Are you aware of it?
I am using a .def file, and my exported functions are being called. That's how I can tell that TLS is not working properly in the first place.
Oct 08 2012
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
08.10.2012 23:06, Jakob Ovrum пишет:
 On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote:
 As I said, give us a runnable failing test suite.
I am working on it, but as I said, it's proving very difficult to replicate outside the XChat environment. I'll try to produce a reduced plugin though.
 As you are running Windows 7 the only reason I see is this nasty trap:
 http://d.puremagic.com/issues/show_bug.cgi?id=8130

 Are you aware of it?
I am using a .def file, and my exported functions are being called. That's how I can tell that TLS is not working properly in the first place.
To reduce called stuff try not to call D runtime initializers as it isn't required to set up TLS on Windows 6.x (as in test libs from my post in this thread). -- Денис В. Шеломовский Denis V. Shelomovskij
Oct 08 2012
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij 
wrote:
 As I said, give us a runnable failing test suite.
Here's a reduced plugin with VisualD project files and all dependencies. http://filesmelt.com/dl/bugdist.rar It uses the standard DllMain, and the only thing xchat_plugin_init contains is this line: xchat_printf(ph, "test = %p:%d", test.ptr, test.length); Where 'test' is a TLS variable of type string[] with no explicit initializer.
Oct 09 2012
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 October 2012 at 08:41:46 UTC, Jakob Ovrum wrote:
 On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij 
 wrote:
 As I said, give us a runnable failing test suite.
Here's a reduced plugin with VisualD project files and all dependencies. http://filesmelt.com/dl/bugdist.rar It uses the standard DllMain, and the only thing xchat_plugin_init contains is this line: xchat_printf(ph, "test = %p:%d", test.ptr, test.length); Where 'test' is a TLS variable of type string[] with no explicit initializer.
The printed garbage value is the same when DllMain is empty. (BTW, to test this, build the DLL and drop it in <HexChat config folder>/addons. The line will then print on startup in the first available chat window)
Oct 09 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
09.10.2012 12:29, Jakob Ovrum пишет:
 On Tuesday, 9 October 2012 at 08:41:46 UTC, Jakob Ovrum wrote:
 On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote:
 As I said, give us a runnable failing test suite.
Here's a reduced plugin with VisualD project files and all dependencies. http://filesmelt.com/dl/bugdist.rar It uses the standard DllMain, and the only thing xchat_plugin_init contains is this line: xchat_printf(ph, "test = %p:%d", test.ptr, test.length); Where 'test' is a TLS variable of type string[] with no explicit initializer.
The printed garbage value is the same when DllMain is empty. (BTW, to test this, build the DLL and drop it in <HexChat config folder>/addons. The line will then print on startup in the first available chat window)
In your `bugdist.rar` bug.dll is fully in this {c|t}rap: http://d.puremagic.com/issues/show_bug.cgi?id=8130 And I have already mentioned it, but you answered "I am using a .def file". -- Денис В. Шеломовский Denis V. Shelomovskij
Oct 09 2012
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 October 2012 at 17:45:07 UTC, Denis Shelomovskij 
wrote:
 In your `bugdist.rar` bug.dll is fully in this {c|t}rap:
 http://d.puremagic.com/issues/show_bug.cgi?id=8130

 And I have already mentioned it, but you answered "I am using a 
 .def file".
Sorry, I was under the impression that VisualD automatically generated and included a .def file, but indeed it doesn't. Adding the barebones .def file fixed the problem. Thanks!
Oct 10 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
10.10.2012 14:50, Jakob Ovrum пишет:
 On Tuesday, 9 October 2012 at 17:45:07 UTC, Denis Shelomovskij wrote:
 In your `bugdist.rar` bug.dll is fully in this {c|t}rap:
 http://d.puremagic.com/issues/show_bug.cgi?id=8130

 And I have already mentioned it, but you answered "I am using a .def
 file".
Sorry, I was under the impression that VisualD automatically generated and included a .def file, but indeed it doesn't. Adding the barebones .def file fixed the problem. Thanks!
It is clearly mentioned in Issue 8130 description that such fixing on IDE level is one of the solutions of the issue. Probably you'd better to read better things you was advised to read. -- Денис В. Шеломовский Denis V. Shelomovskij
Oct 10 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/10/2012 6:57 PM, Denis Shelomovskij wrote:
 10.10.2012 14:50, Jakob Ovrum пишет:
 On Tuesday, 9 October 2012 at 17:45:07 UTC, Denis Shelomovskij wrote:
 In your `bugdist.rar` bug.dll is fully in this {c|t}rap:
 http://d.puremagic.com/issues/show_bug.cgi?id=8130

 And I have already mentioned it, but you answered "I am using a .def
 file".
Sorry, I was under the impression that VisualD automatically generated and included a .def file, but indeed it doesn't. Adding the barebones .def file fixed the problem. Thanks!
It is clearly mentioned in Issue 8130 description that such fixing on IDE level is one of the solutions of the issue. Probably you'd better to read better things you was advised to read.
I'll add a .def file to the default DLL project in Visual D...
Oct 10 2012
prev sibling next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Oct 08 2012
prev sibling parent reply "dnewbie" <run3 myopera.com> writes:
You can try compiling it with GDC!

Please check this thread:
http://forum.dlang.org/thread/nowjthaqnjfrcvqeuiry forum.dlang.org
Oct 09 2012
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 10 October 2012 at 01:31:35 UTC, dnewbie wrote:
 You can try compiling it with GDC!

 Please check this thread:
 http://forum.dlang.org/thread/nowjthaqnjfrcvqeuiry forum.dlang.org
The latest version of TDM MinGW doesn't seem to include all the required utility binaries required by GDC. i.e. I copied the GDC distribution onto the latest TDM MinGW64 release (using the bundle installer), and it still complains about missing libgmp-3.dll and libppl_c-4.dll. The former DLL is quite easy to find in MinGW's download repository, but I can't find the latter DLL anywhere.
Oct 10 2012
parent "jerro" <a a.com> writes:
 i.e. I copied the GDC distribution onto the latest TDM MinGW64 
 release (using the bundle installer), and it still complains 
 about missing libgmp-3.dll and libppl_c-4.dll. The former DLL 
 is quite easy to find in MinGW's download repository, but I 
 can't find the latter DLL anywhere.
The latest TDM MinGW64 uses gcc 4.7.1 and recent MinGW GDC releases use GCC 4.6.1. Maybe that is causing the problem? Try using a TDM MinGW64 build that uses GCC 4.6.1.
Oct 10 2012