[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