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