Windows: Data segment for GC not initialized when using shared MSVCRT

[skl131313]

Well I have an associative array that holds an array of integers, int[][int] basically. For one frame that is run the contents are valid and the code functions normally. The second time around, most of the contents of the array are empty only one valid entry. Then after a few seconds the program fails trying to access an invalid pointer, for the associative array. It was a global variable using __gshared, when I removed that and used thread local storage, it functioned correctly. The code that's affected is in a DLL file (on windows) that is loaded at runtime using Runtime.loadLibrary. I'm also using the SimpleDllMain mixin from core.sys.windows.dll. So it seems that it is being garbage collected for some reason, even though it still exists and is valid. I'm using LDC 1.1.0-beta5.

[rainers]

Are you expecting to share the GC between the DLL and the host application, i.e. does your DLL export gc_setProxy? I don't think this works but in very simple cases, e.g. only for single threaded applications.
Proper DLL support with a shared druntime is being worked on.

Using separate statically linked versions of druntime should work (with 2 GCs), but pointers have to be added as roots to the GC if the only reference to a memory block is passed to the other binary. While a globl variable is usually as good as adding an explicit root, the memory must be allocated by the same GC that knows about the global data segment. Is this the case here, i.e. the associative array is not modified by the executable?

If this does not help, please try to reduce the issue to a reproducable test case.

[skl131313]

@rainers I tried exporting gc_setProxy, didn't seem to work. The array never leaves the DLL, it is only used as a global variable in the DLL.

I tried reducing the code but the error doesn't exist anymore when reduced. Is there any way to debug the GC?

[kinke]

I tried to reproduce it using 2 methods - dynamic loading of the DLL at runtime via rt_loadLibrary() (without the DLL exporting gc_setProxy()) and importing the function directly via import lib. Both work.

import core.memory, core.stdc.stdio;

version(DLL)
{
    import core.sys.windows.dll;

    mixin SimpleDllMain;

    __gshared int[][int] global;

    export extern(C) void foo()
    {
        for (int i = 0; i < 1_000_000; i += 2)
            global[i] = new int[256];

        GC.collect();

        printf("%d entries\n", global.length);
        foreach (i, ref int[] a; global)
            printf("  %d: length = %d, %d\n", i, a.length, a[0]);
    }
}
else
{
    version(USE_IMPORT_LIB) export extern(C) void foo();

    void main()
    {
        version(USE_IMPORT_LIB)
        {
            foo();
        }
        else
        {
            import rt.dmain2, core.sys.windows.windows;
            void* handle = rt_loadLibrary("my.dll");
            alias Action = void function();
            auto f = cast(Action) GetProcAddress(handle, "foo");
            printf("handle: %p, foo(): %p\n", handle, f);
            f();
        }
    }
}

[skl131313]

@kinke Yah I don't have a problem with it when I reduce it as simple as it can be. It must be a problem with the interaction with something else. I have a function (exists in DLL) that gets called every update from the executable. This is where it uses the associative array. If I do the following:

__gshared int[][int] globalArray;

export extern(C) void update()
{
    int[][int] keepIt = globalArray; // remove this and no longer works

    // use globalArray (not keepIt)

}

The above code works, if a reference is kept on the stack. Which makes me think the garbage collector isn't finding the pointer for the __gshared variable. So it seems like it is the garbage collector collecting it as garbage. When it shouldn't be. Something else must be interfering with it?

[rainers]

If you suspect bad GC ranges, you can print them and compare to the addess of your global:

import gc.gc;
import core.demangle;
import core.stdc.stdio;

enum name = mangle!GC("gc.proxy._gc");
extern __gshared pragma(mangle, name) GC xgc;

__gshared int[][int] globalArray;

void main()
{
    printf("&globalArray = %p\n", &globalArray);

    foreach (r; xgc.rangeIter)
        printf("range %p - %p\n", r.pbot, r.ptop);
    foreach (r; xgc.rootIter)
        printf("root  %p\n", r);
}

You need to add the import path to the druntime sources to the compilation command line, though. Unfortunately, these are not included in the prebuilt packages, so grab them here: https://github.com/ldc-developers/druntime/tree/release-1.1.0

[skl131313]

Well it doesn't seem to be in the range. The ranges seem to be only for the executable.

global - 7FFD623E1068

range 000001C2D4B281F0 - 000001C2D4B28208
range 000001C2D4B2F220 - 000001C2D4B2F238
range 000001C2D4B2F310 - 000001C2D4B2F328
range 000001C2D4B2F400 - 000001C2D4B2F418
range 000001C2D4B2F4F0 - 000001C2D4B2F508
range 000001C2D4B2F5E0 - 000001C2D4B2F5F8
range 000001C2D4B2F6D0 - 000001C2D4B2F6E8
range 000001C2D4B2F7C0 - 000001C2D4B2F7D8
range 000001C2D4B2F8B0 - 000001C2D4B2F8C8
range 000001C2D4B2F9A0 - 000001C2D4B2F9B8

[kinke]

I can't confirm this with my trivial sample above:

global 00007FFE707FA3B0
range 00007FFE707F5000 - 00007FFE707FBAD0

Just to make sure: you do link both binaries (exe + DLL) statically against druntime, right?

[skl131313]

Yah I should be, I'm not setting it to use any other library, I'm just using whatever ldmd2 defaults to. Also for the code above it works when set to a local variable on the stack. That local variable isn't in the ranges either. But it still works, it's a bit puzzling.

global = 00007FFD58A00068
local  = 0000001B155BF4D8
range 00000136C0B37FE0 - 00000136C0B37FF8
range 00000136C0B3F140 - 00000136C0B3F158
range 00000136C0B3F230 - 00000136C0B3F248
range 00000136C0B3F320 - 00000136C0B3F338
range 00000136C0B3F410 - 00000136C0B3F428
range 00000136C0B3F500 - 00000136C0B3F518
range 00000136C0B3F5F0 - 00000136C0B3F608
range 00000136C0B3F6E0 - 00000136C0B3F6F8
range 00000136C0B3F7D0 - 00000136C0B3F7E8
range 00000136C0B3F8C0 - 00000136C0B3F8D8
range 00000136C0B3F9C0 - 00000136C0B3F9D8
range 00000136C0B3FAB0 - 00000136C0B3FAC8
range 00000136C0B3FBA0 - 00000136C0B3FBB8
range 00000136C0B3FC90 - 00000136C0B3FCA8

[rainers]

I guess what you see are the ranges of the executable's GC that include main, not the GC of the DLL. You have to add the code somewhere in your DLL, e.g. inside the update function.

Thread local data is not added to the ranges, but is scanned seperately.

[rainers]

Is your pasted output the full list or just a snippet? There doesn't seem to be a sensible data segment included, neither for the executable nor the DLL. Maybe you actually have a DLL export of the broken gc_setProxy (check with dumpbin /EXPORTS).

[skl131313]

Yah that was the entire list. The dumpbin didn't show any gc_setProxy, so "export" doesn't seem to be working there. I added a .def file to export it and now it prints nothing for the ranges. I might just stick with DMD until a shared library is built for LDC. There's another issue where it crashes when unloading the DLL as well.. Thanks for the help, if you have any more suggestions I'll keep trying.

[rainers]

Please do not export gc_setProxy, it's just asking for trouble.

I suspect that the data segment initialization (https://github.com/ldc-developers/druntime/blob/release-1.1.0/src/ldc/msvc.c#L31) is never run (to be called as C++-style initializers). This should show up as an empty range with this:

import rt.sections;
import core.stdc.stdio;

void main() // add this to some code inside the DLL, e.g. update()
{
    foreach (ref sg; SectionGroup)
    {
        foreach (r; sg.gcRanges)
            printf("sgrange %p - %p\n", r.ptr, r.ptr + r.length);
    }
}

[skl131313]

gc_setProxy is never exported then, calling GetProcAddress(lib, "gc_setProxy") returns null.

It prints the following, without gc_setProxy being exported.
sgrange 0000000000000000 - 0000000000000000

[kinke]

So Rainer's suspicion appears to be right. The question is why it's not initialized properly in your case. Can you confirm that my sample above works on your machine (incl. checking the GC ranges)?

[rainers]

Now my first guess is confirmed, I suspect that the C++ initialization does not run, i.e. https://github.com/ldc-developers/druntime/blob/release-1.1.0/src/ldc/msvc.c#L86 has no effect. Are you using special C init code? It would be nice if you could build the DLL with -L/MAP and make the resulting map file available.

BTW: What OS and VS/VC versions are you using?