[Issue 1360] GC emits HLT when GetThreadContext fails after CreateRemoteThread.

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1360





------- Comment #4 from wqeqweuqy at hotmail.com  2007-07-21 15:58 -------
- The "target" application is in C++. 
- The D code is a DLL that wraps some directx COM interfaces and hooks the
target.
- The problematic loader is in C++ using CreateRemoteThread with LoadLibrary.

The loader is injecting the D DLL into the target application. D DLL's Dllmain
calls gc_init, m_init etc for PROCCESS_ATTACH.

The thing is, using the "madChook" library to inject the dll instead, through
its version of "CreateProcessEx" or its system wide "inject on process creation
through a kernel driver" method works perfectly fine. AFAIK both his methods
inject before the target program's entry point is called too. 

It seems like the presence of a CreateRemoteThread call alone is messing up the
GC. Since the GC worked fine, using the madChook method, on that one user's PC
after uninstalling everything that could possibly be injecting unrelated dlls
with CreateRemoteThread. Yahoo messenger, Norton etc. 

It might work better to do a seperate scan of GetCurrentThread() instead of
having a resident non-D Main thread, but that leads to problems if you dont run
a collection cycle before D functions returns to non-D-space. 

A simple solution for DLLs might be to manually initalize what the GC uses as
the main thread somewhere along the line (if needed). And allow it to fall back
on FullCollectNoStack() if theres no Main thread registered. I'm not sure if
this will result in leaks or not though. 

Also, the behavior on that one users PC makes it seem like it could be
something unrelated to initialization that is breaking things too. 

Seems like this is going to be messy to deal with haha.


--