[Issue 1360] GC emits HLT when GetThreadContext fails after CreateRemoteThread.
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Sun Jul 22 21:52:28 PDT 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1360
------- Comment #6 from wqeqweuqy at hotmail.com 2007-07-22 23:52 -------
Heres a temporary fix that seems to solve the problem on that users PC:
Modify DllMain:
-------------------------------
case DLL_PROCESS_ATTACH:
DisableThreadLibraryCalls(instance);
gc_init();
std.gc.disable();
_minit();
_moduleCtor();
return TRUE;
-------------------------------
Extend Thread class:
-------------------------------
static void setAsMainThread()
{
if (!threadLock)
threadLock = new Object();
if (allThreadsDim == -1)
allThreadsDim = 1;
Thread t = new Thread();
t.state = TS.RUNNING;
t.id = GetCurrentThreadId();
t.hdl = Thread.getCurrentThreadHandle();
t.stackBottom = os_query_stackBottom();
t.idx = 0;
allThreads[0] = t;
}
-------------------------------
Then from the programs main thread:
Thread.setAsMainThread();
std.gc.enable();
This issue probably affects people who LoadLibrary() a D DLL from a thread
(during regular execution, not just before the entry point is called) that
disappears sometime during the execution of the program. I think it might be
tricky to reliably figure out what the main thread of a process is. You could
probably enumerate threads and look if the entry point of the thread matches
the entry point of the exe. But i think usually the main thread is allowed to
exit without killing the whole program, as long as some threads are still
active. So theres still the issue of allThreads[0] possibly being invalid
right?
--
More information about the Digitalmars-d-bugs
mailing list