[C++/CLI] Direct access of unmanaged thread_local variable from managed code causes unexpected NullReferenceException

[LEI-Hongfaan]

Description

Consider the following code

// Compile with /clr

#pragma managed(push, off)

thread_local int thread_local_value;

int get_thread_local_value() {
    return thread_local_value;
}

void set_thread_local_value(int value) {
    thread_local_value = value;
}
#pragma managed(pop)

public ref class Test abstract sealed {

public:
    static int ManipulateThreadLocalValue(int value) {
        thread_local_value = value; // Throws a NullReferenceException at runtime
        return thread_local_value;
/* Jitted code
00007FFCF0FCFE70  push        rbp  
00007FFCF0FCFE71  sub         rsp,20h  
00007FFCF0FCFE75  lea         rbp,[rsp+20h]  
00007FFCF0FCFE7A  mov         dword ptr [rbp+10h],ecx  
00007FFCF0FCFE7D  mov         rcx,7FFCF1090020h  
00007FFCF0FCFE87  call        qword ptr [0]  ; <-- ???
00007FFCF0FCFE8E  mov         edx,dword ptr [rbp+10h]  
00007FFCF0FCFE91  mov         dword ptr [rax],edx  
00007FFCF0FCFE93  mov         eax,dword ptr [rbp+10h]  
00007FFCF0FCFE96  lea         rsp,[rbp]  
00007FFCF0FCFE9A  pop         rbp  
00007FFCF0FCFE9B  ret  
*/
    }

    static int ManipulateThreadLocalValue_Workaround(int value) {
        set_thread_local_value(value); // Ok
        return get_thread_local_value();
    }
};

Expected behavior

1. VC++ Compiler should warn about it if not supported. - Or -
2. VC++ Compiler should emit suitable metadata to identify thread_local fields and let the .NET runtime to deal with them. - Or -
3. VC++ Compiler should generate unmanaged stubs to manipulate thread_local fields for the managed code. - Or -
4. .NET jitter should correctly handle unmanaged thread_local field access.

I'm not very sure it's the right place to report the bug. It's more likely a problem of VC++ Compiler.

category:correctness
theme:managed-c++
skill-level:beginner
cost:medium
impact:small

[BruceForstall]

@LEI-Hongfaan What versions of VC++ and .NET are you using?

[BruceForstall]

@dotnet/jit-contrib Anyone familiar with the intersection of VC++ /clr, thread local variables, and JIT?

[jkotas]

This is related to CORINFO_HELP_GETSTATICFIELDADDR_TLS JIT helper:

runtime/src/coreclr/src/inc/jithelpers.h

Line 179 in 6072e4d

JITHELPER(CORINFO_HELP_GETSTATICFIELDADDR_TLS, NULL, CORINFO_HELP_SIG_CANNOT_USE_ALIGN_STUB)

It looks like this helper was not brought back as part of the adding managed C++ support back.

[BruceForstall]

@jkotas, is this a .NET 5 issue?

[jkotas]

.NET 3.1 shipped with this bug. It is not a .NET 3.1 -> 5.0 regression.

We should either fix in both 3.1 and 5.0 or neither.

[BruceForstall]

Marking as 6.0 for now.

[AndyAyersMS]

@BruceForstall still planning on fixing this in 6.0?

[MrMontana1889]

Is there an update on this issue?

I am in the process of testing the migration of one the products I develop and it uses TLS in a mixed-mode C++ project. The TLS code (__declspec(thread)) is in a statically linked C++ library (non-managed) but is accessed from managed C++/CLI (code is now CLI as it was old syntax but the migration was required to target .NET Core 3.1).

The exact same code works perfectly fine with .NET Framework 4.7.2 (which we will also be targeting).

If there is a work around on how to get this to work, I am open to any suggestions.

[Chaotikmind]

Having the same problem here, a simple thread_local static int, is making the application crash
windows 7, net 5.0
i get an access violation at the library initialization