Re: Windows DLLs and TLS
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!
Re: Windows DLLs and TLS
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/nowjthaqnjfrcvqeu...@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.
Re: Windows DLLs and TLS
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
Re: Windows DLLs and TLS
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...
Re: Windows DLLs and TLS
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.
Re: Windows DLLs and TLS
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.
Re: Windows DLLs and TLS
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)
Re: Windows DLLs and TLS
On Mon, 08 Oct 2012 19:32:40 +0100, Jakob Ovrum jakobov...@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/
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 10:21:58 UTC, Regan Heath wrote: On Mon, 08 Oct 2012 19:32:40 +0100, Jakob Ovrum jakobov...@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.
Re: Windows DLLs and TLS
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(Lbug.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
Re: Windows DLLs and TLS
On 10/9/12, Jakob Ovrum jakobov...@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
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 14:09:52 UTC, Andrej Mitrovic wrote: On 10/9/12, Jakob Ovrum jakobov...@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
Re: [OT] Re: Windows DLLs and TLS
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
Re: Windows DLLs and TLS
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
Re: [OT] Re: Windows DLLs and TLS
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.
Re: Windows DLLs and TLS
You can try compiling it with GDC! Please check this thread: http://forum.dlang.org/thread/nowjthaqnjfrcvqeu...@forum.dlang.org
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
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
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.
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.
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.
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
Re: Windows DLLs and TLS
On Mon, 08 Oct 2012 12:26:29 +0100, Jakob Ovrum jakobov...@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/
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).
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 DLL tests.7z Description: application/7z-compressed
[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
Re: Windows DLLs and TLS
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.
Re: Windows DLLs and TLS
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 :(
Re: Windows DLLs and TLS
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
Re: Windows DLLs and TLS
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.
Re: Windows DLLs and TLS
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
Re: [OT] Re: Windows DLLs and TLS
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? ;-)
