[D-runtime] DLL initialization in Druntime

Walter Bright walter at digitalmars.com
Sun Jan 16 11:42:42 PST 2011



Rainer Schuetze wrote:
> Hi,
>
> I have not updated to the latest version yet, but it seems that it's 
> the first time that gc_addRange is called during initialization, and 
> this hits the bug in the gc stub code (obviously, the return 
> statements are missing for the "proxy is null" case).
>
> Even if fixed, the proxy has the problem that anything that has been 
> allocated until the proxy is switched, uses a different heap, because 
> the C-Runtime is not shared between the DLLs. This will cause problems 
> when trying to scan/collect objects.

Right.

>
> I've proposed using a phobos.dll shared between DLLs, but it involves 
> some trickery: http://d.puremagic.com/issues/show_bug.cgi?id=4071
>
> BTW: there is a regression in 2.051 regarding DLLs in a multi-threading
> environment: http://d.puremagic.com/issues/show_bug.cgi?id=5382

This is a mystery, as there is no such variable in src/core/dll_helper.d

>
> Rainer
>
> Walter Bright wrote:
>> It was failing hard with the latest changes on loading Windows DLLs, 
>> so I looked into it.
>>
>> I don't see how it ever could have worked.
>>
>> Note that DLLs link with gcstub.obj, this is because DLLs share the 
>> gc with the caller's gc, instead of having a separate gc that fights 
>> the caller's. The general idea is that upon initialization the DLL 
>> sets "proxy" to point to the caller's gc, and then all gc calls are 
>> routed through the proxy.
>>
>> First, in our DLL's DllMain(), we call:
>>
>>         case DLL_PROCESS_ATTACH:
>>             dll_process_attach(hInstance);
>>
>> In dll_process_attach(), druntime calls:
>>
>>     Runtime.initialize()
>>
>> which calls:
>>
>>     rt_init(null)
>>
>> which calls:
>>
>>    gc_init();
>>    initStaticDataGC();
>>
>> which calls:
>>
>>     gcstub.gc.gc_addRange()
>>
>> which looks like:
>>
>> extern (C) void gc_addRange( void* p, size_t sz )
>> {
>>     printf("gcstub::gc_addRange() proxy = %p\n", proxy);
>>     if( proxy is null )
>>     {
>>         Range* r = cast(Range*) realloc( ranges,
>>                                          (nranges+1) * 
>> ranges[0].sizeof );
>>         if( r is null )
>>             onOutOfMemoryError();
>>         r[nranges].pos = p;
>>         r[nranges].len = sz;
>>         ranges = r;
>>         ++nranges;
>>     }
>>     return proxy.gc_addRange( p, sz );
>> }
>>
>> which will ALWAYS crash because proxy is null. But we never notice 
>> the crash, because rt_init() ignores exceptions when dg is null, as in:
>>
>>     catch (Throwable e)
>>     {
>>         if (dg)
>>             dg(e);
>>     }
>>
>> and things then proceed with a half-crashed uninitialized runtime.
>>
>> *Bugs:*
>>
>> 1. proxy is null. It is supposed to be initialized by 
>> rt_loadLibrary(). But, sadly, it dll_process_attach() gets called 
>> first by LoadLibrary()! Disaster.
>>
>> 2. gcstub's gc_addRange() and gc_addRoot() will always crash if proxy 
>> is null.
>>
>> 3. gc_isCollecting() needs to be added to gcstub.gc. Otherwise, the 
>> linker mixes in gcstub with the regular gc in a truly frankensteinian 
>> mess.
>>
>> 4. rt_init() should not ignore exceptions when dg is null, it should 
>> rethrow them.
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>


More information about the D-runtime mailing list