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.

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 :(

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

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.

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

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? ;-)

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.

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)

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/

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.