thread.d "Unable to load thread context"

Sean Kelly sean at invisibleduck.org
Wed Jun 29 21:33:10 PDT 2011


On Jun 29, 2011, at 10:00 AM, Benjamin Thaut wrote:

> Am 29.06.2011 17:52, schrieb Sean Kelly:
>> I really want to fix this--the current patch is frustrating to deal with--but I don't have the time yet.
>> 
>> Sent from my iPhone
>> 
>> On Jun 29, 2011, at 12:40 AM, "Daniel Murphy"<yebblies at nospamgmail.com>  wrote:
>> 
>>> "Benjamin Thaut"<code at benjamin-thaut.de>  wrote in message
>>> news:iud7qf$16jf$1 at digitalmars.com...
>>>> I just build dmd, druntime and phobos fromt the latest git revision (as
>>>> druntime does not build with dmd 2.053). The game does build with it, but
>>>> as soon as it starts a exception gets thrown in the GC which does not get
>>>> cought by any of my catch blocks.
>>>> Maybe I did something wrong building dmd, is there a guide somewhere?
>>>> 
>>> 
>>> Recent changes have made allocating memory from the GC while a collection is
>>> running (eg inside a class destructor) throw an exception.  Is it possible
>>> your code is doing this?
>>> 
>>> 
> If I manually merge your fix into the thread.d of the 2.053 runtime (change m to __gshared in slock) the issue still exsits. After a while the game will stop with "unable to load thread context".

It seems like there may some weirdness with GetThreadContext.  See for example:

http://stackoverflow.com/questions/3444190/windows-suspendthread-doesnt-getthreadcontext-fails

I'd have to do more digging to see what to try.

> When compiling with the current git revision, it no longer throws this exception but enters _on_out_of_memory and throws a exception from there (although I don't know where the call is coming from because the debugger can't fully resolve the stack). I'm pretty shure though that I'm not out of memory when this happens (windowns task manager shows that there is 1 gig of memory free), and I also checked all desturctors to not allocate memory. So I don't have any clue where that could be coming from.
> The out of memory exception occurs during a full collect.

That part is definitely related to the "throw OOME when a finalizer accesses the GC during a collection."  I plan to fix this, but it isn't trivial in the current GC and I'm revisiting using Leandro's GC instead.  I'm also going to be out of touch for a while, so I likely won't get it done soon.


More information about the Digitalmars-d mailing list