On Mon, 08 Oct 2012 12:26:29 +0100, Jakob Ovrum <[email protected]>
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/
