View mode: basic / threaded / horizontal-split · Log in · Help
October 08, 2012
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.
October 08, 2012
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 :(
October 08, 2012
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
October 08, 2012
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.
October 08, 2012
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
October 08, 2012
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? ;-)
October 09, 2012
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.
October 09, 2012
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)
October 09, 2012
Re: Windows DLLs and TLS
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/
October 09, 2012
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 
> <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.
1 2 3 4
Top | Discussion index | About this forum | D home