.NET application hangs some time after loading NativeAOT-compiled library

[ethframe]

Description

.NET application randomly hangs after loading NativeAOT-compiled shared library inside code related to NativeAOT runtime of that library.

Reproduction Steps

I've yet to find minimal repro, but outline of steps is something like this:

1. Launch application that uses async.
2. Application loads NativeAOT-compiled library in worker thread at some point.
3. Now SIGRTMIN sent to worker threads first handled by NativeAOT runtime.
4. Application's GC tries to pause threads when one of them inside malloc call.
5. NativeAOT's signal handler tries to allocate tls and causes nested malloc call, which deadlocks.

Expected behavior

NativeAOT-compiled shared library does not interfere with main application.

Actual behavior

One of application threads got locked in nested malloc call:

Thread 25 (Thread 0x7f5e9dc836c0 (LWP 1742873) ".NET TP Worker"):
#0  0x00007f5f1dc900d6 in __lll_lock_wait_private () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f5f1dca2bb8 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f5f1e124dde in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00007f5f1e128398 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
#4  0x00007f1da08d2328 in ThreadStore::RawGetCurrentThread () at /__w/1/s/src/coreclr/nativeaot/Runtime/./threadstore.inl:14
#5  ThreadStore::GetCurrentThreadIfAvailable () at /__w/1/s/src/coreclr/nativeaot/Runtime/./threadstore.inl:31
#6  ActivationHandler (code=34, siginfo=0x7f5e9dc823f0, context=0x7f5e9dc822c0) at /__w/1/s/src/coreclr/nativeaot/Runtime/unix/PalRedhawkUnix.cpp:1059
#7  <signal handler called>
#8  0x00007f5f1dca163c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x00007f5f1dca2989 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x00007f5f1d916169 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.10/libcoreclr.so
#11 0x00007f5f1d71de42 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.10/libcoreclr.so
#12 0x00007f5f1d7ac182 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.10/libcoreclr.so
#13 0x00007f5ea711b397 in ?? ()
#14 0x00007f5f1c442608 in ?? ()
#15 0x000000001828144f in ?? ()
#16 0x00007f5f1dae73c8 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.10/libcoreclr.so
#17 0x00007f5e9dc82cd0 in ?? ()
#18 0x0000000000000000 in ?? ()

Regression?

No response

Known Workarounds

No response

Configuration

• Application: .NET 8.0.10
• Shared library: .NET 8.0.1
• OS: Debian 12

Other information

It seems that signal handler shouldn't try to access __thread variables at all, since they are not async-signal-safe.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[ethframe]

I've managed to reproduce the deadlock:

Ubuntu 24.04.3 (on WSL)
.NET 8.0.21

Thread 5 (Thread 0x793ea24cc6c0 (LWP 1226177) "GcHang"):
#0  futex_wait (private=0, expected=2, futex_word=0x793e80000030) at ../sysdeps/nptl/futex-internal.h:146
#1  __GI___lll_lock_wait_private (futex=futex@entry=0x793e80000030) at ./nptl/lowlevellock.c:34
#2  0x000079c0718ad920 in __GI___libc_malloc (bytes=264) at ./malloc/malloc.c:3334
#3  0x000079c072067bde in malloc (size=<optimized out>) at ../include/rtld-malloc.h:56
#4  allocate_dtv_entry (size=<optimized out>, alignment=8) at ../elf/dl-tls.c:679
#5  allocate_and_init (map=0x797f380021e0) at ../elf/dl-tls.c:704
#6  tls_get_addr_tail (ti=0x79c06c3b8f78, dtv=0x59382a2e08e0, the_map=0x797f380021e0) at ../elf/dl-tls.c:904
#7  0x000079c07206b85c in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55
#8  0x000079c06c2904d8 in ThreadStore::RawGetCurrentThread () at /__w/1/s/src/coreclr/nativeaot/Runtime/./threadstore.inl:14
#9  ThreadStore::GetCurrentThreadIfAvailable () at /__w/1/s/src/coreclr/nativeaot/Runtime/./threadstore.inl:31
#10 ActivationHandler (code=34, siginfo=0x793ea24cb0b0, context=0x793ea24caf80) at /__w/1/s/src/coreclr/nativeaot/Runtime/unix/PalRedhawkUnix.cpp:1060
#11 <signal handler called>
#12 heap_trim (pad=131072, heap=0x793e80000000) at ./malloc/arena.c:586
#13 _int_free_maybe_consolidate (av=0x793e80000030, size=<optimized out>) at ./malloc/malloc.c:4795
#14 0x000079c0718ab43a in _int_free (av=0x793e80000030, p=<optimized out>, have_lock=<optimized out>) at ./malloc/malloc.c:4646
#15 0x000079c0718addae in __GI___libc_free (mem=0x793e80002540) at ./malloc/malloc.c:3398
#16 0x000079c0718954c5 in __GI__IO_setb (f=f@entry=0x793e80001f50, b=b@entry=0x0, eb=eb@entry=0x0, a=a@entry=0) at ./libio/genops.c:331
#17 0x000079c071891997 in _IO_new_file_close_it (fp=fp@entry=0x793e80001f50) at ./libio/fileops.c:153
#18 0x000079c0718853a1 in _IO_new_fclose (fp=0x793e80001f50) at ./libio/iofclose.c:53
#19 0x000079c07160225e in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#20 0x000079c071603bb2 in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#21 0x000079c071602b9d in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#22 0x000079c071480352 in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#23 0x000079c0714b0bd3 in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#24 0x000079c0713295d2 in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#25 0x000079c07132931c in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#26 0x000079c07134865f in ?? () from /usr/lib/dotnet/shared/Microsoft.NETCore.App/8.0.21/libcoreclr.so
#27 0x000079bff2d24728 in ?? ()
#28 0x0000797ff0137048 in ?? ()
#29 0x0000797ff0137048 in ?? ()

NativeAOT library:

namespace GcHang.Native;

using System.Runtime.InteropServices;


public static class Api
{
    [UnmanagedCallersOnly(EntryPoint = "nop")]
    public static void Nop() { }
}

Main program:

using GcHang;
using System.Runtime.InteropServices;

Console.WriteLine($"PID: {System.Diagnostics.Process.GetCurrentProcess().Id}");

Thread thread = new(TriggerLoad);
thread.Start();
thread.Join();

Queue<Thread> threads = [];
const int nThreads = 20;

for (var i = 0; i < nThreads; i++)
{
    thread = new(Worker);
    thread.Start();
    threads.Enqueue(thread);
}

int count = 0;

while (true)
{
    thread = threads.Dequeue();
    thread.Join();
    count++;
    thread = new(Worker);
    thread.Start();
    threads.Enqueue(thread);

    if (count % nThreads == 0)
    {
        Console.WriteLine($"{count} threads joined");
    }
}

void Worker()
{
    const int nItems = 100000;
    List<object> list = [];

    for (int i = 0; i < nItems; i++)
    {
        list.Add(new object());
    }
}

void TriggerLoad()
{
    Api.Nop();
}

public static class Api
{
    [DefaultDllImportSearchPaths(DllImportSearchPath.AssemblyDirectory)]
    [DllImport("GcHang.Native", EntryPoint = "nop")]
    public static extern void Nop();
}

[HJLeee]

FYI,
Seems like an old corner case in glibc.
https://sourceware.org/legacy-ml/libc-alpha/2012-06/msg00335.html

Below is a similar call stack caught by ASAN in Tizen.

0xf51a9340 is located 0 bytes inside of 320-byte region [0xf51a9340,0xf51a9480)
freed by thread T11 here:
    #0 0xf75fa26e in realloc.part.0 (/usr/lib/libasan.so+0x9e26e) (BuildId: 9bba7c7c1d333d26085dc332318addcdddefc51d)
    #1 0xf7b11ae4 in _dl_resize_dtv (/lib/ld-linux.so.3+0x41010ae4) (BuildId: 09e97ca6a7629ff5a7bcdd346a4f7a5508203c59)
    #2 0xf7b12500 in _dl_update_slotinfo (/lib/ld-linux.so.3+0x41011500) (BuildId: 09e97ca6a7629ff5a7bcdd346a4f7a5508203c59)
    #3 0xf7b1265c in update_get_addr (/lib/ld-linux.so.3+0x4101165c) (BuildId: 09e97ca6a7629ff5a7bcdd346a4f7a5508203c59)
    #4 0xf75dd5ea in __tls_get_addr (/usr/lib/libasan.so+0x815ea) (BuildId: 9bba7c7c1d333d26085dc332318addcdddefc51d)
    #5 0xf24062da in CheckActivationSafePoint(unsigned int) (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0x1792da) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #6 0xf2571cc8 in inject_activation_handler(int, siginfo_t*, void*) (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0x2e4cc8) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #7 0xf71ace0c  (/lib/libc.so.6+0x41242e0c) (BuildId: 4d66a597c3674cb64087a6587522a00c688b8037)
    #8 0xf7605700 in __sanitizer::BufferedStackTrace::UnwindImpl(unsigned int, unsigned int, void*, bool, unsigned int) (/usr/lib/libasan.so+0xa9700) (BuildId: 9bba7c7c1d333d26085dc332318addcdddefc51d)
    #9 0xf75fa298 in realloc.part.0 (/usr/lib/libasan.so+0x9e298) (BuildId: 9bba7c7c1d333d26085dc332318addcdddefc51d)
    #10 0xf7b11ae4 in _dl_resize_dtv (/lib/ld-linux.so.3+0x41010ae4) (BuildId: 09e97ca6a7629ff5a7bcdd346a4f7a5508203c59)
    #11 0xf7b12500 in _dl_update_slotinfo (/lib/ld-linux.so.3+0x41011500) (BuildId: 09e97ca6a7629ff5a7bcdd346a4f7a5508203c59)
    #12 0xf7b1265c in update_get_addr (/lib/ld-linux.so.3+0x4101165c) (BuildId: 09e97ca6a7629ff5a7bcdd346a4f7a5508203c59)
    #13 0xf75dd5ea in __tls_get_addr (/usr/lib/libasan.so+0x815ea) (BuildId: 9bba7c7c1d333d26085dc332318addcdddefc51d)
    #14 0xf235d62a in ManagedThreadBase_DispatchMiddle(ManagedThreadCallState*)::Cleanup::~Cleanup() (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0xd062a) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #15 0xf235c926 in ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0xcf926) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #16 0xf235cb60 in ManagedThreadBase::KickOff(void (*)(void*), void*) (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0xcfb60) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #17 0xf238a274 in ThreadNative::KickOffThread(void*) (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0xfd274) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #18 0xf25912d8 in CorUnix::CPalThread::ThreadEntry(void*) (/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libcoreclr.so+0x3042d8) (BuildId: 78a8db7ede0a62b8ff150e5a58e4c5dad06019e3)
    #19 0xf75a1eda in asan_thread_start(void*) (/usr/lib/libasan.so+0x45eda) (BuildId: 9bba7c7c1d333d26085dc332318addcdddefc51d)
    #20 0xf71f0cb0 in start_thread (/lib/libc.so.6+0x41286cb0) (BuildId: 4d66a597c3674cb64087a6587522a00c688b8037)

cc/ @dotnet/samsung

[ethframe]

Well, no need to have a .NET application, even two different NativeAOT libraries could cause this deadlock:

Thread 15 (Thread 0x741ac54ca6c0 (LWP 148380) "main"):
#0  futex_wait (private=0, expected=2, futex_word=0x741a6c000030) at ../sysdeps/nptl/futex-internal.h:146
#1  __GI___lll_lock_wait_private (futex=futex@entry=0x741a6c000030) at ./nptl/lowlevellock.c:34
#2  0x0000749bfd8ad920 in __GI___libc_malloc (bytes=264) at ./malloc/malloc.c:3334
#3  0x0000749bfda77bde in malloc (size=<optimized out>) at ../include/rtld-malloc.h:56
#4  allocate_dtv_entry (size=<optimized out>, alignment=8) at ../elf/dl-tls.c:679
#5  allocate_and_init (map=0x749bf8000ba0) at ../elf/dl-tls.c:704
#6  tls_get_addr_tail (ti=0x749bfcfb7f78, dtv=0x59f036eb7990, the_map=0x749bf8000ba0) at ../elf/dl-tls.c:904
#7  0x0000749bfda7b85c in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55
#8  0x0000749bfce8f4d8 in ThreadStore::RawGetCurrentThread () at /__w/1/s/src/coreclr/nativeaot/Runtime/./threadstore.inl:14
#9  ThreadStore::GetCurrentThreadIfAvailable () at /__w/1/s/src/coreclr/nativeaot/Runtime/./threadstore.inl:31
#10 ActivationHandler (code=34, siginfo=0x741ac54c9530, context=0x741ac54c9400) at /__w/1/s/src/coreclr/nativeaot/Runtime/unix/PalRedhawkUnix.cpp:1060
#11 <signal handler called>
#12 0x0000749bfd8aacd0 in heap_max_size () at ./malloc/arena.c:572
#13 heap_for_ptr (ptr=0x741a6c001400) at ./malloc/arena.c:146
#14 _int_free_maybe_consolidate (av=0x741a6c000030, size=<optimized out>) at ./malloc/malloc.c:4792
#15 0x0000749bfd8ab43a in _int_free (av=0x741a6c000030, p=<optimized out>, have_lock=<optimized out>) at ./malloc/malloc.c:4646
#16 0x0000749bfd8addae in __GI___libc_free (mem=0x741a6c001410) at ./malloc/malloc.c:3398
#17 0x0000749bfd8954c5 in __GI__IO_setb (f=f@entry=0x741a6c000da0, b=b@entry=0x0, eb=eb@entry=0x0, a=a@entry=0) at ./libio/genops.c:331
#18 0x0000749bfd891997 in _IO_new_file_close_it (fp=fp@entry=0x741a6c000da0) at ./libio/fileops.c:153
#19 0x0000749bfd8853a1 in _IO_new_fclose (fp=0x741a6c000da0) at ./libio/iofclose.c:53
#20 0x0000749bfc2dcf5e in ReadMemoryValueFromFile (filename=<optimized out>, val=val@entry=0x741ac54c9b88) at /__w/1/s/src/coreclr/gc/unix/gcenv.unix.cpp:792
#21 0x0000749bfc2de42e in (anonymous namespace)::CGroup::GetPhysicalMemoryLimit (val=0x741ac54c9b88) at /__w/1/s/src/coreclr/gc/unix/cgroup.cpp:376
#22 GetRestrictedPhysicalMemoryLimit () at /__w/1/s/src/coreclr/gc/unix/cgroup.cpp:477
#23 0x0000749bfc2dd637 in GCToOSInterface::GetPhysicalMemoryLimit (refresh=false, is_restricted=<optimized out>) at /__w/1/s/src/coreclr/gc/unix/gcenv.unix.cpp:1133
#24 GCToOSInterface::GetMemoryStatus (restricted_limit=<optimized out>, memory_load=0x741ac54c9c7c, available_physical=0x0, available_page_file=0x0) at /__w/1/s/src/coreclr/gc/unix/gcenv.unix.cpp:1320
#25 0x0000749bfc2a38bb in WKS::gc_heap::get_memory_info (memory_load=0x741ac54c9c7c, available_physical=0x0, available_page_file=0x0) at /__w/1/s/src/coreclr/nativeaot/Runtime/../../gc/gc.cpp:28840
#26 WKS::gc_heap::wait_for_bgc_high_memory (awr=WKS::awr_gen0_alloc, loh_p=<optimized out>, msl_status=<optimized out>) at /__w/1/s/src/coreclr/nativeaot/Runtime/../../gc/gc.cpp:18080
#27 WKS::gc_heap::try_allocate_more_space (acontext=acontext@entry=0x741ac54c9cd0, size=size@entry=524344, flags=flags@entry=34, gen_number=gen_number@entry=3) at /__w/1/s/src/coreclr/nativeaot/Runtime/../../gc/gc.cpp:19276
#28 0x0000749bfc2ccbb3 in WKS::gc_heap::allocate_more_space (acontext=0x741ac54c9cd0, size=524344, flags=34, alloc_generation_number=3) at /__w/1/s/src/coreclr/nativeaot/Runtime/../../gc/gc.cpp:19795
#29 WKS::gc_heap::allocate_uoh_object (jsize=524312, flags=34, gen_number=<optimized out>, alloc_bytes=@0x741a6c000ba8: 393264) at /__w/1/s/src/coreclr/nativeaot/Runtime/../../gc/gc.cpp:45154
#30 WKS::GCHeap::Alloc (this=<optimized out>, context=0x741a6c000b90, size=524312, flags=34) at /__w/1/s/src/coreclr/nativeaot/Runtime/../../gc/gc.cpp:49673
#31 0x0000749bfc28dae0 in GcAllocInternal (pEEType=0x749bfc44a4e8, uFlags=34, numElements=65536, pThread=0x741a6c000b90) at /__w/1/s/src/coreclr/nativeaot/Runtime/gcrhenv.cpp:195
#32 RhpGcAlloc (pEEType=0x749bfc44a4e8, uFlags=<optimized out>, numElements=65536, pTransitionFrame=<optimized out>) at /__w/1/s/src/coreclr/nativeaot/Runtime/gcrhenv.cpp:257
#33 0x0000749bfc2e7c14 in RhpNewArrayRare () at /__w/1/s/src/coreclr/nativeaot/Runtime/amd64/AllocFast.S:290
#34 0x0000749bfc3567fc in __set_Capacity (this=..., value=130048) at /_/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/List.cs:111
#35 0x0000749bfc3568a1 in __AddWithResize (this=..., item=...) at /_/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/List.cs:218
#36 0x0000749bfc2f9068 in GcHang_Native_Worker_GcHang_Native_Worker_Api__Worker () at /_/gchang/src/GcHang.Native.Worker/Api.cs:47
#37 0x0000749bfc31c7ce in S_P_CoreLib_System_Threading_Thread__StartThread (parameter=127656829911088) at /_/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/Thread.NativeAot.cs:447
#38 0x0000749bfc31cb79 in S_P_CoreLib_System_Threading_Thread__ThreadEntryPoint (parameter=<optimized out>) at /_/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/Thread.NativeAot.Unix.cs:113
#39 0x0000749bfd89caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#40 0x0000749bfd929c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

First library:

namespace GcHang.Native;

using System.Runtime.InteropServices;

public static class Api
{
    [UnmanagedCallersOnly(EntryPoint = "nop")]
    public static void Nop() { }
}

Second library:

namespace GcHang.Native.Worker;

using System.Runtime.InteropServices;

public static class Api
{
    [UnmanagedCallersOnly(EntryPoint = "start_worker")]
    public static void StartWorker()
    {
        const int nThreads = 20;
        Queue<Thread> threads = [];

        Thread thread;

        for (var i = 0; i < nThreads; i++)
        {
            thread = new(Worker);
            thread.Start();
            threads.Enqueue(thread);
        }

        int count = 0;

        while (true)
        {
            thread = threads.Dequeue();
            thread.Join();
            count++;
            thread = new(Worker);
            thread.Start();
            threads.Enqueue(thread);

            if (count % nThreads == 0)
            {
                Console.WriteLine($"{count} threads joined");
            }
        }
    }

    private static void Worker()
    {
        const int nItems = 100000;
        List<object> list = [];

        for (int i = 0; i < nItems; i++)
        {
            list.Add(new object());
        }
    }
}

Main program:

#include <dlfcn.h>
#include <pthread.h>

void* trigger_load(void*) {
    void *handle;
    void (*nop)();

    handle = dlopen("./GcHang.Native.so", RTLD_LAZY);
    nop = dlsym(handle, "nop");

    nop();

    return NULL;
}

int main() {
    void *handle;
    void (*start_worker)();

    pthread_t thread;

    pthread_create(&thread, NULL, trigger_load, NULL);
    pthread_join(thread, NULL);

    handle = dlopen("./GcHang.Native.Worker.so", RTLD_LAZY);
    start_worker = dlsym(handle, "start_worker");

    start_worker();
}

[jkotas]

I guess we need to roll our own signal-safe thread-statics based on gettid (the only signal-safe way to identify current thread that I can find) and use it to check whether the current thread has been initialized. Return null from GetCurrentThreadIfAvailable if it was not initialized.

[janvorli]

pthread_self() is listed in the async signal safe list too, so that's another option.

[fweimer-rh]

If you compile the relevant code with -ftls-model=initial-exec, TLS access will be async-signal-safe. However, on glibc, you may not be able to use dlopen to load this code. The musl C library rejects loading of initial-exec TLS shared objects outright.

Does the issue happen on AArch64? If not, on x86-64, then building with -mtls-dialect=gnu2 could mitigate it there as well. That's because GNU2 TLS descriptors effectively have initial-exec behavior (and are therefore async-signal-safe) if the shared object defining the TLS variable is loaded early enough. However, on x86-64, GCC and glibc disagreed about the GNU2 TLS descriptor calling convention until fairly recently, which had its own set of problems.

If you need async-safe global-dynamic TLS support in glibc, please file an RFE/bug report with an appropriate GNU/Linux toolchain team. This is fixable in principle (and backportable), it just needs to be prioritized.

[janvorli]

@fweimer-rh thank you for the details! I have a pending PR #122048 that prevents .NET runtime access to TLS in the specific async signal handler unless we can be sure that the interrupted location is in the JIT or AOT compiled .NET code and thus it cannot be in a libc memory allocator. I think it is more friendly to the async safety and linux ecosystem than requesting async safe global-dynamic TLS support. Moreover, we also support MUSL and macOS and we need something that is guaranteed to be correct for those platforms.

[fweimer-rh]

@fweimer-rh thank you for the details! I have a pending PR #122048 that prevents .NET runtime access to TLS in the specific async signal handler unless we can be sure that the interrupted location is in the JIT or AOT compiled .NET code and thus it cannot be in a libc memory allocator. I think it is more friendly to the async safety and linux ecosystem than requesting async safe global-dynamic TLS support. Moreover, we also support MUSL and macOS and we need something that is guaranteed to be correct for those platforms.

This way seems to be a much better approach.

Musl always had an async-signal-safe __tls_get_addr, so you wouldn't build binaries for it with -ftls-model=initial-exec. Sorry, should have mentioned that.