View mode: basic / threaded / horizontal-split · Log in · Help
October 09, 2012
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(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
October 09, 2012
Re: Windows DLLs and TLS
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
October 09, 2012
Re: Windows DLLs and TLS
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
October 09, 2012
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
October 09, 2012
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
October 09, 2012
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.
October 10, 2012
Re: Windows DLLs and TLS
You can try compiling it with GDC!

Please check this thread:
http://forum.dlang.org/thread/nowjthaqnjfrcvqeuiry@forum.dlang.org
October 10, 2012
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!
October 10, 2012
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/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.
October 10, 2012
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
1 2 3 4
Top | Discussion index | About this forum | D home