search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.43k stars 4.76k forks source link

Mono does not implement coreclr_create_delegate hosting API or ComponentActivator #59815

Open jkoritzinsky opened 3 years ago

jkoritzinsky commented 3 years ago

Update the hosting API has been added to Mono. This issue is mainly open now to track the remaining work needed in order to run the DllImportGenerator tests on mobile platforms (or indeed other apps that may want the desktop hosting API on mobile). See https://github.com/dotnet/runtime/issues/59815#issuecomment-932456674 for one path forward.

Mono does not implement the coreclr_create_delegate hosting API method nor the ComponentActivator class used by the nethost library. This is blocking us from running the DllImportGenerator.Tests suite, since we use DNNE to enable easier managed->native testing in the libraries suite by implementing the "native" side primarily in managed code.

dotnet-issue-labeler[bot] commented 3 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

lambdageek commented 3 years ago

@jkoritzinsky This CompnentActivator ? What's DNNE - I'm not familiar with the acronym.

jkoritzinsky commented 3 years ago

Yes, that is the ComponentActivator I'm referring to. DNNE is DotNetNativeExports, an project that @AaronRobinsonMSFT started that makes exposing managed code as native exports much simpler (and has significantly streamlined our ability to test the DllImportGenerator source generator).

lambdageek commented 3 years ago

@jkoritzinsky What's a good way to get an overview of how the DllImportGenerator testing is designed? You're telling me some pieces and I'm having a hard time putting the whole thing together in my head.

@steveisok I think we need to have a discussion about how this testing will look on mobile.

AaronRobinsonMSFT commented 3 years ago

What's a good way to get an overview of how the DllImportGenerator testing is designed?

@lambdageek The design is pretty simple. The tests are XUnit based and have a series of P/Invoke signatures. The DNNE package generates native platform library that represents specific exports from the managed assembly. When the test P/Invokes into the generated native library it does two things: (1) verifies the runtime is loaded and (2) finds the associated managed function that was indicated to be exported. Loading the runtime is straight forward enough and mono supports that without issue. However, discovery of the managed function by returning a function pointer to that function isn't. That is typically done via coreclr_create_delegate. The basic scenario is similar to what is documented at https://docs.microsoft.com/dotnet/core/tutorials/netcore-hosting.

DNNE's implementation can be found at https://github.com/AaronRobinsonMSFT/DNNE/blob/master/src/platform/platform.c.

lambdageek commented 3 years ago

The DNNE package generates native platform library that represents specific exports from the managed assembly.

ok, I think I understand so far.

In C# you write a P/Invoke declaration. It's body is some boilerplate that ultimately calls back to C#. DNNE generates that boilerplate. Then from a C# xunit test you invoke the P/Invoke, that calls into the generated native library which invokes a managed method and the managed method records the test success in some way?

When the test P/Invokes into the generated native library it does two things: (1) verifies the runtime is loaded and (2) finds the associated managed function that was indicated to be exported.

I'm unclear on what (1) means. Isn't this axiomatically true: the runtime is loaded because the test is running. Maybe I'm misunderstanding what DNNE platform.c is doing - is it really initializing a new runtime? (in a separate process?) or it just needs to get some handle that it can then use to get the function pointer to the managed method?

I'm slightly unclear on what (2) means: essentially you want to get back to managed land from native. One way to have done that was to use something like GetFunctionPointerForDelegate which would require passing the function pointer from managed to native. But an alternate approach is to call coreclr_create_delegate directory and get the pointer from the runtime. Is that what's going on?

The bigger issue is that Mono does not have corehost (and hence the corefxr entrypoints) on mobile. But it doesn't seem like that's an essential part of this scheme - you could use the coreclr_initialize, coreclr_create_delegate functions directly, right?

AaronRobinsonMSFT commented 3 years ago

DNNE itself is typically used for providing native exports of managed assemblies. The generated native library can be consumed naturally from a native application and the fact that the underlying implementation is managed is an implementation detail that is hidden.

The usage of DNNE in this case is to avoid having any explicit native assets to test the DllImport source generator. Testing the DllImport source generator then becomes entirely managed with the the thin native veneer useful to properly consume the test target via P/Invoke.

For (1), yes in this scenario the runtime will already be initialized and that is handled opaquely by hostfxr so DNNE and the test harness don't care. For (2) that is part of the veneer and an implementation detail of DNNE that the test relies upon. We could have written this all in native code but then we would have to introduce CMake and all that nonsense so we avoid that by using DNNE.

But an alternate approach is to call coreclr_create_delegate directory and get the pointer from the runtime. Is that what's going on?

That isn't the alternative approach that is how DNNE works - imagine a world where a managed assembly wants to provide the implementation to native and only project a native API. The way to do that is via DNNE and a small bit of C code that hides the runtime activation and managed to function pointer conversion away.

lambdageek commented 3 years ago

Thanks for the clarifications @jkoritzinsky @AaronRobinsonMSFT.

For (1), yes in this scenario the runtime will already be initialized and that is handled opaquely by hostfxr so DNNE and the test harness don't care. For (2) that is part of the veneer and an implementation detail of DNNE that the test relies upon. We could have written this all in native code but then we would have to introduce CMake and all that nonsense so we avoid that by using DNNE.

Ok, great. So I understood what's going on ;-)

But an alternate approach is to call coreclr_create_delegate directory and get the pointer from the runtime. Is that what's going on?

That isn't the alternative approach that is how DNNE works - imagine a world where a managed assembly wants to provide the implementation to native and only project a native API. The way to do that is via DNNE and a small bit of C code that hides the runtime activation and managed to function pointer conversion away.

I didn't mean that it's an alternative for DNNE. Just trying to make sure I understand what the tests are meant to do.

So I think in summary to run on mobile where dynamic linking is allowed we would need to:

  1. Run dnne-gen
  2. Compile the resulting code with the compiler toolchain for the target plaform (Android NDK, or the Xcode SDK for ios)
  3. Either use the real hostfxr and a mono-mobile-specific hostpolicy or a stub standalone hostfxr that cuts through all the indirection and just calls the mono coreclr_XXX functions directly.
  4. Finally implement coreclr_create_delegate (this is yet another variation on mono_marshal_get_managed_wrapper+mono_ldftn; or more ambitiously it's a call to the appropriate function in ComponentActivator in mono SPC))

For static linking (ie ios device builds; and webassembly) we'd need to do... something else - probably a different version of DNNE's platform.c where we can statically link the runtime plus DNNE-created libraries plus the DNNE platform code into a single executable.

AaronRobinsonMSFT commented 3 years ago

@lambdageek I don't fully understand why all these steps are needed in this case. Is it because of mono's hosting semantics? I was assuming we could treat DNNE generated native libraries as if they were any other native binary – P/Invoke into them and be none the wiser?

Step (4) is all that I was expecting as actual work.

lambdageek commented 3 years ago

@lambdageek I don't fully understand why all these steps are needed in this case.

@AaronRobinsonMSFT My assumption is: we want to run the dll import generator tests on Android,ios and wasm, not just on Linux & mac desktops with Mono instead of CoreCLR as the underlying runtime.

If we only want to run on desktops then (4) is sufficient.

Is it because of mono's hosting semantics?

I'd say it's the hosting model, rather than something specific to mono. There's no nethost, hostfxr or hostpolicy on mobile and any code that depends on them will not work.

I was assuming we could treat DNNE generated native libraries as if they were any other native binary – P/Invoke into them and be none the wiser?

The DNNE generated native libraries are probably ok (assuming we compile them with the right toolchain). But they depend on nethost, hostfxr and hostpolicy, right? So the functions that platform.c depends on get_hostfxr_path, hostfxr_get_runtime_delegate etc are not present on mobile.

We haven't tried the desktop versions of hostfxr and hostpolicy on mobile - I have no idea how much work is required to get them working. (If I had to guess... Android and iOS Simulator are probably not too much work - they may even just work if we start building them and bundling them into the tests; iOS device and WebAssembly probably require moderate to significant changes since they're static linking platforms).

My guess is that the most straightforward way would be to build a mobile hostfxr library that exports the symbols that DNNE needs but implements them by directly calling the coreclr_ functions in the current process (ie there's no hostpolicy layer, and the implementation assumes the runtime is already loaded in the current process). Then the only other change needed is platform.c would need to skip get_hostfxr_path and get the symbols from RTLD_DEFAULT.

AaronRobinsonMSFT commented 3 years ago

If we only want to run on desktops then (4) is sufficient.

The scope was what I was missing here. Thanks for the details.

am11 commented 3 years ago

+1 for corehost support on mobile (simulators for the starters). and +2 for a true static linking support (e.g. $ file singlefilehost_static to return ... statically linked, with debug_info, not stripped) 🙂

lambdageek commented 3 years ago

+1 for corehost support on mobile (simulators for the starters)

@am11 I'm curious why you say that. What is the usecase? From my perspective all of the logic of "find the right runtime to run this managed code" is already mostly irrelevant in self-contained desktop scenarios, and is completely useless on mobile - you run what's in the app bundle - there are no choices.

steveisok commented 3 years ago

My guess is that the most straightforward way would be to build a mobile hostfxr library that exports the symbols that DNNE needs but implements them by directly calling the coreclr_ functions in the current process (ie there's no hostpolicy layer, and the implementation assumes the runtime is already loaded in the current process). Then the only other change needed is platform.c would need to skip get_hostfxr_path and get the symbols from RTLD_DEFAULT.

@AaronRobinsonMSFT @lambdageek I can have someone on my team look to provide the mobile libraries. Safe to assume you would like this sooner rather than later?

am11 commented 3 years ago

What is the usecase?

Mainly non-production/xamarin; I was coming from:

all of the logic of "find the right runtime to run this managed code" is already mostly irrelevant in self-contained desktop scenarios

Yup, there are still some implementation details even in self-contained e.g. how it uses user configuration json files, finds the hook in (coreclr) runtime and exports symbols for sos/diagnostics etc. I think making the same (familiar) hosts work on various platforms will open avenues for broader scenarios.

lambdageek commented 3 years ago

Ok, mono on desktop platforms should support this now. (lightly verified by trying a DNNE sample with Mono https://github.com/lambdageek/dnne_monovm_sample)

Mobile requires a bunch of host work. A new thing I found out is that ComponentActivator (or rather IsolatedLoadContext) depends on AssemblyDependencyResolver, which in turn depends on hostpolicy being on the device (or hostpolicy pinvoke overrides as is done for coreclr single file). See https://github.com/dotnet/runtime/issues/59961 for related work

jkoritzinsky commented 3 years ago

@lambdageek I'm trying this out with the DllImportGenerator.Tests test suite and I'm seeing the following error messages (and crashes resulting from double faults/SIGABRTs/etc):

mono_coop_cond_timedwait Cannot transition thread 0x7f698d61f700 from STATE_BLOCKING with DO_BLOCKING
mono_coop_mutex_lock Cannot transition thread 0x7f698ce1b700 from STATE_BLOCKING with DO_BLOCKING
mono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f698d61f700 from STATE_BLOCKING with DO_BLOCKING

They don't seem to consistently happen due to a specific test, so I'm not sure exactly what's going on.

lambdageek commented 3 years ago

@jkoritzinsky are there stack traces in the logs? How do I run the DllImportGenerator.Tests suite - I think I will need to repro locally.

@lambdageek I'm trying this out with the DllImportGenerator.Tests test suite and I'm seeing the following error messages (and crashes resulting from double faults/SIGABRTs/etc):

mono_coop_cond_timedwait Cannot transition thread 0x7f698d61f700 from STATE_BLOCKING with DO_BLOCKING
mono_coop_mutex_lock Cannot transition thread 0x7f698ce1b700 from STATE_BLOCKING with DO_BLOCKING
mono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f698d61f700 from STATE_BLOCKING with DO_BLOCKING

They don't seem to consistently happen due to a specific test, so I'm not sure exactly what's going on.

jkoritzinsky commented 3 years ago

Here's the output from Mono's dump (this is in a release build):

mono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f0c0a514700 from STATE_BLOCKING with DO_BLOCKING

=================================================================
        Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
        Native stacktrace:
=================================================================
        0x7f0c15348732 - Unknown
        0x7f0c152ede1e - Unknown
        0x7f0c15348008 - Unknown
        0x7f0c16615980 - Unknown
        0x7f0c1570dfb7 - Unknown
        0x7f0c1570f921 - Unknown
        0x7f0c15396d65 - Unknown
        0x7f0c151e0543 - Unknown
        0x7f0c15397125 - Unknown
        0x7f0c1539725e - Unknown
        0x7f0c151f02bc - Unknown
        0x7f0c151f19d1 - Unknown
        0x7f0c151f1a67 - Unknown
        0x404f98a3 - Unknown

=================================================================
        External Debugger Dump:
=================================================================
mono_coop_cond_timedwait Cannot transition thread 0x7f0c09d10700 from STATE_BLOCKING with DO_BLOCKING
=================================================================
        Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

An error has occured in the native fault reporting. Some diagnostic information will be unavailable.

=================================================================
        Native stacktrace:
=================================================================
        0x7f0c15348732 - Unknown
        0x7f0c152ede1e - Unknown
        0x7f0c15251b31 - Unknown
        0x7f0c16615980 - Unknown
        0x404a5417 - Unknown

=================================================================
        External Debugger Dump:
=================================================================
mono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f0c09b0f700 from STATE_BLOCKING with DO_BLOCKINGmono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f0c09f11700 from STATE_BLOCKING with DO_BLOCKINGmono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f0c0a112700 from STATE_BLOCKING with DO_BLOCKINGmono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f0c0a715700 from STATE_BLOCKING with DO_BLOCKING[New LWP 9440]
[New LWP 9441]
[New LWP 9442]
[New LWP 9444]
[New LWP 9447]
[New LWP 9448]
[New LWP 9449]
[New LWP 9450]
[New LWP 9451]
[New LWP 9452]
[New LWP 9453]
[New LWP 9454]
[New LWP 9455]
[New LWP 9456]
[New LWP 9457]
[New LWP 9458]
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
/tmp/mono-gdb-commands.9439:1: Error in sourced command file:
warning: process 9439 is already traced by process 9459
ptrace: Operation not permitted.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f0c16610ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x562abe8bc6e4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
88      ../sysdeps/unix/sysv/linux/futex-internal.h: No such file or directory.
  Id   Target Id         Frame 
* 1    Thread 0x7f0c16a30740 (LWP 9439) "dotnet" 0x00007f0c16610ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x562abe8bc6e4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  2    Thread 0x7f0c147ff700 (LWP 9440) "SGen worker" 0x00007f0c16610ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f0c156c64dc <work_cond+44>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  3    Thread 0x7f0c12bff700 (LWP 9441) "dotnet" 0x00007f0c157e3cb9 in __GI___poll (fds=0x7f0c0c002d40, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  4    Thread 0x7f0c129fe700 (LWP 9442) "Finalizer" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  5    Thread 0x7f0c0b58f700 (LWP 9444) "dotnet" 0x00007f0c16614474 in __libc_read (fd=9, buf=0x7f0c0b58eebb, nbytes=1) at ../sysdeps/unix/sysv/linux/read.c:27
  6    Thread 0x7f0c0ad76700 (LWP 9447) ".NET Long Runni" mono_stack_mark_pop (info=<optimized out>, stackmark=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/handle.h:166
  7    Thread 0x7f0c0ab75700 (LWP 9448) ".NET ThreadPool" 0x00007f0c16610fb9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f0c0ab746a0, expected=0, futex_word=0x7f0bfc008c90) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
  8    Thread 0x7f0c0a96e700 (LWP 9449) ".NET ThreadPool" 0x00007f0c16610fb9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f0c0a96d810, expected=0, futex_word=0x7f0bf00467c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
  9    Thread 0x7f0c0a92c700 (LWP 9450) ".NET ThreadPool" 0x00007f0c16610fb9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f0c0a92b890, expected=0, futex_word=0x7f0c0a92b9c8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
  10   Thread 0x7f0c0a715700 (LWP 9451) ".NET Long Runni" 0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
  11   Thread 0x7f0c0a514700 (LWP 9452) ".NET Long Runni" 0x00007f0c1661532a in __waitpid (pid=9459, stat_loc=0x7f0c0a50ea40, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  12   Thread 0x7f0c0a313700 (LWP 9453) ".NET Long Runni" 0x00007f0c1661532a in __waitpid (pid=9460, stat_loc=0x7f0c0a30e6c0, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  13   Thread 0x7f0c0a112700 (LWP 9454) ".NET Long Runni" 0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
  14   Thread 0x7f0c09f11700 (LWP 9455) ".NET Long Runni" 0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
  15   Thread 0x7f0c09d10700 (LWP 9456) ".NET Long Runni" 0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
  16   Thread 0x7f0c09b0f700 (LWP 9457) ".NET Long Runni" 0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
  17   Thread 0x7f0c0990e700 (LWP 9458) ".NET Long Runni" 0x00007f0c1511530d in mono_class_from_mono_type_internal (type=0x562abe1ee340) at /home/jekoritz/runtime2/src/mono/mono/metadata/class.c:2171

Thread 17 (Thread 0x7f0c0990e700 (LWP 9458)):
#0  0x00007f0c1511530d in mono_class_from_mono_type_internal (type=0x562abe1ee340) at /home/jekoritz/runtime2/src/mono/mono/metadata/class.c:2171
#1  0x00007f0c15116e36 in mono_class_is_variant_compatible (klass=0x562abe1ecaa0, oklass=<optimized out>, check_for_reference_conv=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/class.c:3631
#2  0x00007f0c15116a52 in mono_class_interface_offset_with_variance (klass=0x562abe7b9368, itf=0x562abe1ecaa0, non_exact_match=0x7f0c0990b8ec) at /home/jekoritz/runtime2/src/mono/mono/metadata/class.c:1931
#3  0x00007f0c152ef980 in mini_resolve_imt_method (vt=0x7f0be4095ec8, vtable_slot=0x7f0be4095e90, imt_method=0x562abe1f76e0, impl_method=0x7f0c0990b9a0, out_aot_addr=0x7f0c0990b9c0, out_need_rgctx_tramp=0x7f0c0990b96c, variant_iface=0x7f0c0990b998, error=0x7f0c0990ba28) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-trampolines.c:205
#4  0x00007f0c152f0127 in common_call_trampoline (regs=<optimized out>, code=<optimized out>, m=0x0, vt=<optimized out>, vtable_slot=0x7f0be4095e90, error=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-trampolines.c:471
#5  0x00007f0c152f122e in mono_vcall_trampoline (regs=0x7f0c0990bad8, code=0x40592335 "H\213\310H\213D$\030H\203\300\060H\211\bH\211L$\020H\213\320H\301\352\tH\201\342\377\377\177", slot=-7, tramp=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-trampolines.c:852
#6  0x0000000040165296 in ?? ()
#7  0x00007f0bd4002455 in ?? ()
#8  0x00007f0c14976560 in ?? ()
#9  0x00007f0c0990bca0 in ?? ()
#10 0x00007f0c0990bad8 in ?? ()
#11 0x00007f0bd4001be0 in ?? ()
#12 0x00007f0be4095ec8 in ?? ()
#13 0x0000000000000011 in ?? ()
#14 0x00007f0c0990ea30 in ?? ()
#15 0x00007f0c0964f0b0 in ?? ()
#16 0x00007f0c0990bca0 in ?? ()
#17 0x00007f0c0990c2a0 in ?? ()
#18 0x0000000000000001 in ?? ()
#19 0x00007f0c14976560 in ?? ()
#20 0x00007f0c0990b928 in ?? ()
#21 0x0000000000000000 in ?? ()

Thread 16 (Thread 0x7f0c09b0f700 (LWP 9457)):
#0  0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
#1  0x00007f0c151f19d1 in mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x7f0bd0000b20, stackdata=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:322
#2  0x00007f0c151f1a67 in mono_threads_enter_gc_safe_region_unbalanced_internal (stackdata=0x7f0c09b0b948) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:288
#3  mono_threads_enter_gc_safe_region_unbalanced (stackpointer=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:296
#4  0x00000000404f98a3 in ?? ()
#5  0x00007f0c09b0bd10 in ?? ()
#6  0x0000562abe7baf60 in ?? ()
#7  0x00007f0c09b0bc48 in ?? ()
#8  0x000000000000000c in ?? ()
#9  0x000000000000001a in ?? ()
#10 0x00007f0bd0000b20 in ?? ()
#11 0x00007f0c153ef68f in ?? () from /home/jekoritz/runtime2/artifacts/bin/testhost/net7.0-Linux-Release-x64/shared/Microsoft.NETCore.App/7.0.0/libcoreclr.so
#12 0x00007f0c09b0bb18 in ?? ()
#13 0x00007f0c09b0bba0 in ?? ()
#14 0x00007f0c09b0b960 in ?? ()
#15 0x00007f0c0936637a in ?? () from /home/jekoritz/runtime2/artifacts/bin/DllImportGenerator.Tests/net7.0-Release/Microsoft.Interop.Tests.NativeExportsNE.so
#16 0x00007f0c1518da74 in mono_threads_detach_coop_internal (cookie=0x0, stackdata=0x7f0c09b0b9c8) at /home/jekoritz/runtime2/src/mono/mono/metadata/threads.c:4754
#17 mono_threads_detach_coop (orig=<optimized out>, dummy=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/threads.c:4772
#18 0x00000000404f978c in ?? ()
#19 0x000000000000001a in ?? ()
#20 0x00000000404f974c in ?? ()
#21 0x000000000000001a in ?? ()
#22 0x00000000404a54b8 in ?? ()
#23 0x00007f0c09b0bba0 in ?? ()
#24 0x0000562abe7baf60 in ?? ()
#25 0x00007f0c09b0bc48 in ?? ()
#26 0x00007f0bd0001be0 in ?? ()
#27 0x00007f0c09b0bb50 in ?? ()
#28 0x00007f0c09b0ba50 in ?? ()
#29 0x00007f0c09b0ba80 in ?? ()
#30 0x00007f0c151f2008 in copy_stack_data_internal (info=<optimized out>, stackdata_begin=0x7f0c09b0bd10, wrapper_data1=<optimized out>, wrapper_data2=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:193
#31 copy_stack_data (info=0x1a, stackdata_begin=0x7f0c09b0bd10) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:246
#32 0x000000004065b1f8 in ?? ()
#33 0x00007f0c12c49360 in ?? ()
#34 0x0000000000000000 in ?? ()

Thread 15 (Thread 0x7f0c09d10700 (LWP 9456)):
#0  0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
#1  0x00007f0c151f19d1 in mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x7f0bdc000b20, stackdata=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:322
#2  0x00007f0c151b4d42 in mono_coop_cond_timedwait (cond=<optimized out>, mutex=<optimized out>, timeout_ms=4294967295) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-coop-mutex.h:101
#3  coop_cond_timedwait_alertable (cond=0x7f0c156b7330 <pending_done_cond>, mutex=0x7f0c156b7300 <pending_done_mutex>, timeout_ms=4294967295, alertable=0x7f0c09d0ca74) at /home/jekoritz/runtime2/src/mono/mono/metadata/gc.c:164
#4  ves_icall_System_GC_WaitForPendingFinalizers () at /home/jekoritz/runtime2/src/mono/mono/metadata/gc.c:625
#5  0x0000000040673987 in ?? ()
#6  0x00007f0c09d0cd10 in ?? ()
#7  0x0000562abe7bb160 in ?? ()
#8  0x00007f0c09d0cc48 in ?? ()
#9  0x0000000000000000 in ?? ()

Thread 14 (Thread 0x7f0c09f11700 (LWP 9455)):
#0  0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
#1  0x00007f0c151f19d1 in mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x7f0bd8000b20, stackdata=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:322
#2  0x00007f0c151f1a67 in mono_threads_enter_gc_safe_region_unbalanced_internal (stackdata=0x7f0c09f0d7c8) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:288
#3  mono_threads_enter_gc_safe_region_unbalanced (stackpointer=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:296
#4  0x00000000404f98a3 in ?? ()
#5  0x00007f0bd80acb40 in ?? ()
#6  0x00007f0c14847df8 in ?? ()
#7  0x00007f0bd8001be0 in ?? ()
#8  0x00007f0c09f0d9f0 in ?? ()
#9  0x0000000000000018 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 13 (Thread 0x7f0c0a112700 (LWP 9454)):
#0  0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
#1  0x00007f0c151f19d1 in mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x7f0be4000b20, stackdata=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:322
#2  0x00007f0c151f1a67 in mono_threads_enter_gc_safe_region_unbalanced_internal (stackdata=0x7f0c0a10e648) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:288
#3  mono_threads_enter_gc_safe_region_unbalanced (stackpointer=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:296
#4  0x00000000404f98a3 in ?? ()
#5  0x00007f0c0a10e840 in ?? ()
#6  0x00007f0c12c00280 in ?? ()
#7  0x00007f0c0a10e840 in ?? ()
#8  0x000000000000000d in ?? ()
#9  0x000000000000000e in ?? ()
#10 0x00007f0be4000b20 in ?? ()
#11 0x00007f0c153ef68f in ?? () from /home/jekoritz/runtime2/artifacts/bin/testhost/net7.0-Linux-Release-x64/shared/Microsoft.NETCore.App/7.0.0/libcoreclr.so
#12 0x00007f0c0a10e808 in ?? ()
#13 0x00007f0c0a10e9b0 in ?? ()
#14 0x00007f0c0a10e660 in ?? ()
#15 0x00007f0c09366310 in ?? () from /home/jekoritz/runtime2/artifacts/bin/DllImportGenerator.Tests/net7.0-Release/Microsoft.Interop.Tests.NativeExportsNE.so
#16 0x00007f0c1518da74 in mono_threads_detach_coop_internal (cookie=0x0, stackdata=0x7f0c0a10e6c8) at /home/jekoritz/runtime2/src/mono/mono/metadata/threads.c:4754
#17 mono_threads_detach_coop (orig=<optimized out>, dummy=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/threads.c:4772
#18 0x00000000404f978c in ?? ()
#19 0x000000000000000e in ?? ()
#20 0x00000000404f974c in ?? ()
#21 0x000000000000000e in ?? ()
#22 0x00000000404a5cc8 in ?? ()
#23 0x00007f0c0a10e9b0 in ?? ()
#24 0x00007f0c12c00280 in ?? ()
#25 0x00007f0c0a10e840 in ?? ()
#26 0x00007f0be4001be0 in ?? ()
#27 0x00007f0c0a10e840 in ?? ()
#28 0x00007f0c151f2008 in copy_stack_data_internal (info=<optimized out>, stackdata_begin=0x7f0c0a10e840, wrapper_data1=<optimized out>, wrapper_data2=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:193
#29 copy_stack_data (info=0xe, stackdata_begin=0x7f0c0a10e840) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:246
#30 0x0000000040693374 in ?? ()
#31 0x0000000040693320 in ?? ()
#32 0x0000000000000000 in ?? ()

Thread 12 (Thread 0x7f0c0a313700 (LWP 9453)):
#0  0x00007f0c1661532a in __waitpid (pid=9460, stat_loc=0x7f0c0a30e6c0, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x00007f0c15348877 in dump_native_stacktrace (signal=<optimized out>, mctx=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-posix.c:842
#2  mono_dump_native_crash_info (signal=<optimized out>, mctx=0x7f0c0a30f230, info=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-posix.c:869
#3  0x00007f0c152ede1e in mono_handle_native_crash (signal=0x7f0c15402991 "SIGSEGV", mctx=0x7f0c0a30f230, info=0x7f0c0a30f4f0) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-exceptions.c:2940
#4  0x00007f0c15251b31 in mono_sigsegv_signal_handler_debug (_dummy=11, _info=0x7f0c0a30f4f0, context=0x7f0c0a30f3c0, debug_fault_addr=0x2500000018) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-runtime.c:3719
#5  <signal handler called>
#6  0x00000000404a5417 in ?? ()
#7  0x0000002500000018 in ?? ()
#8  0x0000000000000076 in ?? ()
#9  0x0000000000000004 in ?? ()
#10 0x0000000000000076 in ?? ()
#11 0x0000000000000004 in ?? ()
#12 0x000000000000003b in ?? ()
#13 0x0000000000000002 in ?? ()
#14 0x000000004065d93d in ?? ()
#15 0x00007f0c0a30fd10 in ?? ()
#16 0x0000562abe7ba858 in ?? ()
#17 0x00007f0c0a30fc48 in ?? ()
#18 0x00007f0c14803be8 in ?? ()
#19 0x000000004065d170 in ?? ()
#20 0x00007f0c0a30fa58 in ?? ()
#21 0x00007f0c0a30fe38 in ?? ()
#22 0x00007f0c15150e9d in mono_os_mutex_unlock (mutex=0x2500000018) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-os-mutex.h:127
#23 mono_coop_mutex_unlock (mutex=0x2500000018) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-coop-mutex.h:71
#24 mono_loader_unlock () at /home/jekoritz/runtime2/src/mono/mono/metadata/loader.c:142
#25 0x00007f0c151201ac in mono_class_create_from_typedef (image=0x562abe7ba858, type_token=1080414576, error=0x7f0c0a30fc30) at /home/jekoritz/runtime2/src/mono/mono/metadata/class-init.c:445
#26 0x0000000000000000 in ?? ()

Thread 11 (Thread 0x7f0c0a514700 (LWP 9452)):
#0  0x00007f0c1661532a in __waitpid (pid=9459, stat_loc=0x7f0c0a50ea40, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x00007f0c15348877 in dump_native_stacktrace (signal=<optimized out>, mctx=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-posix.c:842
#2  mono_dump_native_crash_info (signal=<optimized out>, mctx=0x7f0c0a50f558, info=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-posix.c:869
#3  0x00007f0c152ede1e in mono_handle_native_crash (signal=0x7f0c15402972 "SIGABRT", mctx=0x7f0c0a50f558, info=0x7f0c0a50f830) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-exceptions.c:2940
#4  0x00007f0c15348008 in sigabrt_signal_handler (_dummy=<optimized out>, _info=0x7f0c0a50f830, context=0x7f0c0a50f700) at /home/jekoritz/runtime2/src/mono/mono/mini/mini-posix.c:224
#5  <signal handler called>
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7  0x00007f0c1570f921 in __GI_abort () at abort.c:79
#8  0x00007f0c15396d65 in monoeg_assert_abort () at /home/jekoritz/runtime2/src/mono/mono/eglib/goutput.c:57
#9  0x00007f0c151e0543 in mono_log_write_logfile (log_domain=<optimized out>, level=<optimized out>, hdr=<optimized out>, message=0x7f0bec0a43c0 "mono_threads_enter_gc_safe_region_unbalanced Cannot transition thread 0x7f0c0a514700 from STATE_BLOCKING with DO_BLOCKING") at /home/jekoritz/runtime2/src/mono/mono/utils/mono-log-common.c:136
#10 0x00007f0c15397125 in monoeg_g_logstr (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, msg=0x0) at /home/jekoritz/runtime2/src/mono/mono/eglib/goutput.c:151
#11 monoeg_g_logv_nofree (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>, args=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/eglib/goutput.c:166
#12 monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/eglib/goutput.c:173
#13 0x00007f0c1539725e in monoeg_g_log (log_domain=0x2 <error: Cannot access memory at address 0x2>, log_level=173079744, format=0x0) at /home/jekoritz/runtime2/src/mono/mono/eglib/goutput.c:182
#14 0x00007f0c151f02bc in mono_threads_transition_do_blocking (info=<optimized out>, func=0x8 <error: Cannot access memory at address 0x8>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
#15 0x00007f0c151f19d1 in mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x7f0bec000b20, stackdata=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:322
#16 0x00007f0c151f1a67 in mono_threads_enter_gc_safe_region_unbalanced_internal (stackdata=0x7f0c0a510528) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:288
#17 mono_threads_enter_gc_safe_region_unbalanced (stackpointer=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:296
#18 0x00000000404f98a3 in ?? ()
#19 0x00007f0c0a510b40 in ?? ()
#20 0x0000562abe7bb350 in ?? ()
#21 0x00007f0bec001e40 in ?? ()
#22 0x0000000000000018 in ?? ()
#23 0x0000000000000018 in ?? ()
#24 0x000000004065d12b in ?? ()
#25 0x00007f0c09366216 in ?? () from /home/jekoritz/runtime2/artifacts/bin/DllImportGenerator.Tests/net7.0-Release/Microsoft.Interop.Tests.NativeExportsNE.so
#26 0x00007f0c0a5106b8 in ?? ()
#27 0x00007f0c0a510750 in ?? ()
#28 0x00007f0c0a510540 in ?? ()
#29 0x00007f0c153ef68f in ?? () from /home/jekoritz/runtime2/artifacts/bin/testhost/net7.0-Linux-Release-x64/shared/Microsoft.NETCore.App/7.0.0/libcoreclr.so
#30 0x00007f0c09366216 in ?? () from /home/jekoritz/runtime2/artifacts/bin/DllImportGenerator.Tests/net7.0-Release/Microsoft.Interop.Tests.NativeExportsNE.so
#31 0x0000000200000000 in ?? ()
#32 0x00000000404f97d8 in ?? ()
#33 0x00007f0c1485e0c0 in ?? ()
#34 0x00000000404f978c in ?? ()
#35 0x0000000000000018 in ?? ()
#36 0x00000000404f974c in ?? ()
#37 0x0000000000000018 in ?? ()
#38 0x000000004065dcf8 in ?? ()
#39 0x00007f0c0a510b40 in ?? ()
#40 0x0000562abe7bb350 in ?? ()
#41 0x00007f0bec001e40 in ?? ()
#42 0xffffffff80070057 in ?? ()
#43 0x00007f0c0a510728 in ?? ()
#44 0x0000000000000000 in ?? ()

Thread 10 (Thread 0x7f0c0a715700 (LWP 9451)):
#0  0x00007f0c151f02c0 in mono_threads_transition_do_blocking (info=<optimized out>, func=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-state-machine.c:759
#1  0x00007f0c151f19d1 in mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x7f0be8000b20, stackdata=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:322
#2  0x00007f0c151f1a67 in mono_threads_enter_gc_safe_region_unbalanced_internal (stackdata=0x7f0c0a711258) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:288
#3  mono_threads_enter_gc_safe_region_unbalanced (stackpointer=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-threads-coop.c:296
#4  0x00000000404f98a3 in ?? ()
#5  0x0000000000000000 in ?? ()

Thread 9 (Thread 0x7f0c0a92c700 (LWP 9450)):
#0  0x00007f0c16610fb9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f0c0a92b890, expected=0, futex_word=0x7f0c0a92b9c8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7f0c0a92b948, mutex=0x7f0bf8062da0, cond=0x7f0c0a92b9a0) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x7f0c0a92b9a0, mutex=0x7f0bf8062da0, abstime=0x7f0c0a92b948) at pthread_cond_wait.c:667
#3  0x00007f0c151e28c4 in mono_os_cond_timedwait (cond=0x7f0c0a92b9a0, mutex=0x7f0bf8062da0, timeout_ms=20000) at /home/jekoritz/runtime2/src/mono/mono/utils/mono-os-mutex.c:75
#4  0x00007f0c151e9bc4 in mono_coop_cond_timedwait (cond=0x7f0c0a92b9a0, mutex=<optimized out>, timeout_ms=20000) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-coop-mutex.h:103
#5  mono_lifo_semaphore_timed_wait (semaphore=0x7f0bf8062da0, timeout_ms=20000) at /home/jekoritz/runtime2/src/mono/mono/utils/lifo-semaphore.c:48
#6  0x0000000040604097 in ?? ()
#7  0x0000000000000008 in ?? ()
#8  0x0000000000000046 in ?? ()
#9  0x00007f0c14bcbec8 in ?? ()
#10 0x00007f0c14bcbec8 in ?? ()
#11 0x0000000000004e20 in ?? ()
#12 0x00007f0bf4002450 in ?? ()
#13 0x0000000000000046 in ?? ()
#14 0x00007f0c0a92ba10 in ?? ()
#15 0x0000000000000046 in ?? ()
#16 0x0000000040603fd8 in ?? ()
#17 0x00007f0c14bcbec8 in ?? ()
#18 0x0000000000004e20 in ?? ()
#19 0x0000000000000046 in ?? ()
#20 0x0000000040603734 in ?? ()
#21 0x0000000000004e20 in ?? ()
#22 0x0000000000000000 in ?? ()

Thread 8 (Thread 0x7f0c0a96e700 (LWP 9449)):
#0  0x00007f0c16610fb9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f0c0a96d810, expected=0, futex_word=0x7f0bf00467c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7f0c0a96d8b0, mutex=0x7f0bf0046770, cond=0x7f0bf0046798) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x7f0bf0046798, mutex=0x7f0bf0046770, abstime=0x7f0c0a96d8b0) at pthread_cond_wait.c:667
#3  0x00007f0c123f91a7 in SystemNative_LowLevelMonitor_TimedWait (monitor=0x7f0bf0046770, timeoutMilliseconds=500) at /home/jekoritz/runtime2/src/libraries/Native/Unix/System.Native/pal_threading.c:192
#4  0x0000000040601047 in ?? ()
#5  0x0000000071fb2bce in ?? ()
#6  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x7f0c0ab75700 (LWP 9448)):
#0  0x00007f0c16610fb9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f0c0ab746a0, expected=0, futex_word=0x7f0bfc008c90) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7f0c0ab74740, mutex=0x7f0bfc008c40, cond=0x7f0bfc008c68) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x7f0bfc008c68, mutex=0x7f0bfc008c40, abstime=0x7f0c0ab74740) at pthread_cond_wait.c:667
#3  0x00007f0c123f91a7 in SystemNative_LowLevelMonitor_TimedWait (monitor=0x7f0bfc008c40, timeoutMilliseconds=12000) at /home/jekoritz/runtime2/src/libraries/Native/Unix/System.Native/pal_threading.c:192
#4  0x0000000040601047 in ?? ()
#5  0x0000000071fb2bce in ?? ()
#6  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7f0c0ad76700 (LWP 9447)):
#0  mono_stack_mark_pop (info=<optimized out>, stackmark=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/handle.h:166
#1  ves_icall_RuntimeTypeHandle_GetCorElementType_raw (a0=0x7f0c0ad75710) at /home/jekoritz/runtime2/src/mono/mono/metadata/icall-def-netcore.h:405
#2  0x0000000040564824 in ?? ()
#3  0x00007f0c09621710 in ?? ()
#4  0x0000000000000001 in ?? ()
#5  0x00007f0c1499f448 in ?? ()
#6  0x00007f0c149716d0 in ?? ()
#7  0x00007f0c12c2ac28 in ?? ()
#8  0x00007f0bf8009400 in ?? ()
#9  0x00007f0c0ad758d0 in ?? ()
#10 0x00007f0c0ad756d0 in ?? ()
#11 0x00007f0c12c2ac28 in ?? ()
#12 0x000000004056475c in ?? ()
#13 0x00007f0c12c2ac28 in ?? ()
#14 0x000000004056471c in ?? ()
#15 0x00007f0c12c2ac28 in ?? ()
#16 0x00000000405646e0 in ?? ()
#17 0x00007f0c12c2ac28 in ?? ()
#18 0x0000000040564610 in ?? ()
#19 0x0000000000000001 in ?? ()
#20 0x00007f0c1499f448 in ?? ()
#21 0x00007f0c149716d0 in ?? ()
#22 0x00007f0c12c2ac28 in ?? ()
#23 0x00007f0c096e8a90 in ?? ()
#24 0x000000004058e8f8 in ?? ()
#25 0x00007f0c1499f448 in ?? ()
#26 0x00007f0c149716d0 in ?? ()
#27 0x00007f0c1480d700 in ?? ()
#28 0x00007f0c096e8a90 in ?? ()
#29 0x00007f0c09621710 in ?? ()
#30 0x00000000405a8dfc in ?? ()
#31 0x00007f0c09611630 in ?? ()
#32 0x0000562abea93468 in ?? ()
#33 0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f0c0b58f700 (LWP 9444)):
#0  0x00007f0c16614474 in __libc_read (fd=9, buf=0x7f0c0b58eebb, nbytes=1) at ../sysdeps/unix/sysv/linux/read.c:27
#1  0x00007f0c123f8d7f in SignalHandlerLoop (arg=<optimized out>) at /home/jekoritz/runtime2/src/libraries/Native/Unix/System.Native/pal_signal.c:321
#2  0x00007f0c1660a6db in start_thread (arg=0x7f0c0b58f700) at pthread_create.c:463
#3  0x00007f0c157f071f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7f0c129fe700 (LWP 9442)):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f0c1660d025 in __GI___pthread_mutex_lock (mutex=0x7f0c156b7300 <pending_done_mutex>) at ../nptl/pthread_mutex_lock.c:80
#2  0x00007f0c151b4730 in mono_os_mutex_lock (mutex=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-os-mutex.h:105
#3  mono_coop_mutex_lock (mutex=0x7f0c156b7300 <pending_done_mutex>) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-coop-mutex.h:57
#4  0x00007f0c151b5ec3 in finalizer_thread (unused=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/gc.c:900
#5  0x00007f0c1518e11a in start_wrapper_internal (start_info=0x0, stack_ptr=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/metadata/threads.c:1200
#6  0x00007f0c1518dfa9 in start_wrapper (data=0x562abe19d900) at /home/jekoritz/runtime2/src/mono/mono/metadata/threads.c:1262
#7  0x00007f0c1660a6db in start_thread (arg=0x7f0c129fe700) at pthread_create.c:463
#8  0x00007f0c157f071f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f0c12bff700 (LWP 9441)):
#0  0x00007f0c157e3cb9 in __GI___poll (fds=0x7f0c0c002d40, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f0c153e534a in ipc_poll_fds (fds=<optimized out>, nfds=1, timeout=4294967295) at /home/jekoritz/runtime2/src/native/eventpipe/ds-ipc-pal-socket.c:470
#2  ds_ipc_poll (poll_handles_data=0x7f0c0c002530, poll_handles_data_len=1, timeout_ms=4294967295, callback=0x7f0c153e4840 <server_warning_callback>) at /home/jekoritz/runtime2/src/native/eventpipe/ds-ipc-pal-socket.c:1082
#3  0x00007f0c153e2995 in ds_ipc_stream_factory_get_next_available_stream (callback=0x7f0c153e4840 <server_warning_callback>) at /home/jekoritz/runtime2/src/native/eventpipe/ds-ipc.c:395
#4  0x00007f0c153e11f9 in server_thread (data=<optimized out>) at /home/jekoritz/runtime2/src/native/eventpipe/ds-server.c:127
#5  0x00007f0c153e4821 in ep_rt_thread_mono_start_func (data=0x562abe181f60) at /home/jekoritz/runtime2/src/mono/mono/mini/../eventpipe/ep-rt-mono.h:1266
#6  0x00007f0c1660a6db in start_thread (arg=0x7f0c12bff700) at pthread_create.c:463
#7  0x00007f0c157f071f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f0c147ff700 (LWP 9440)):
#0  0x00007f0c16610ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f0c156c64dc <work_cond+44>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x7f0c156c6488 <lock>, cond=0x7f0c156c64b0 <work_cond>) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x7f0c156c64b0 <work_cond>, mutex=0x7f0c156c6488 <lock>) at pthread_cond_wait.c:655
#3  0x00007f0c152393b3 in mono_os_cond_wait (cond=<optimized out>, mutex=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/mini/../../mono/utils/mono-os-mutex.h:219
#4  get_work (worker_index=<optimized out>, work_context=<optimized out>, do_idle=<optimized out>, job=<optimized out>) at /home/jekoritz/runtime2/src/mono/mono/sgen/sgen-thread-pool.c:167
#5  thread_func (data=0x0) at /home/jekoritz/runtime2/src/mono/mono/sgen/sgen-thread-pool.c:198
#6  0x00007f0c1660a6db in start_thread (arg=0x7f0c147ff700) at pthread_create.c:463
#7  0x00007f0c157f071f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f0c16a30740 (LWP 9439)):
#0  0x00007f0c16610ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x562abe8bc6e4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x562abe8bc690, cond=0x562abe8bc6b8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x562abe8bc6b8, mutex=0x562abe8bc690) at pthread_cond_wait.c:655
#3  0x00000000405b6d7c in ?? ()
#4  0x00007f0c14bba208 in ?? ()
#5  0x00007f0c14aaf318 in ?? ()
#6  0xffffffffffffffff in ?? ()
#7  0x0000000000000001 in ?? ()
#8  0x00007f0c14aaf348 in ?? ()
#9  0x00007f0c14aaf318 in ?? ()
#10 0xffffffffffffffff in ?? ()
#11 0x0000562abe179220 in ?? ()
#12 0x00007ffcceff92e0 in ?? ()
#13 0x00007ffcceff91f0 in ?? ()
#14 0x0000562abe114eb0 in ?? ()
#15 0x00000000405b6b6c in ?? ()
#16 0xffffffffffffffff in ?? ()
#17 0x00000000405b6b2c in ?? ()
#18 0x00007f0c14aaf348 in ?? ()
#19 0x00000000405b6208 in ?? ()
#20 0x0000562abe0b1cd0 in ?? ()
#21 0x0000000000000000 in ?? ()

Exiting early due to double fault.

Here's what I did to repro:

  1. Check out the feature/use-dllimport-generator branch.
  2. Merge the main branch into that branch to get the implementation of coreclr_get_delegate.
  3. Remove the src/libraries/System.Runtime.InteropServices/tests/DllImportGenerator.Tests/AssemblyInfo.cs file to remove the "skip on mono" attribute.
  4. Run ./build.sh mono+libs -c Release
  5. Run ./dotnet.sh build /t:Test -c Release src/libraries/System.Runtime.InteropServices/tests/DllImportGenerator.Tests/DllImportGenerator.Tests.csproj

That should show you the failures, as well as give you repro instructions to directly run the test process without the dotnet test layer in the middle using the XUnit console runner.

lambdageek commented 3 years ago

@jkoritzinsky thanks I'll take a look.

Best guess so far is that ComponentActivator.InternalGetFunctionPointer isn't doing the right thing on Mono - either wrapping a managed method too many times or not enough times. I suspect we're missing a check for UnmanagedCallersOnly somewhere on the native side in mono for methodInfo.MethodHandle.GetFunctionPointer(). Probably won't be a difficult fix once I find where the problem is.

lambdageek commented 3 years ago

Yea so it's failing in the call to Interop.Sys.Malloc in methods like

        [UnmanagedCallersOnly(EntryPoint = "hresult_out_ushort_string")]
        public static int ReturnAsOutString(int hr, ushort** ret)
        {
            string str = hr.ToString();
            *ret = (ushort*)Marshal.StringToCoTaskMemUni(str);     /// this is Interop.Sys.Malloc
            return hr;
        }

because evidently we're already in GC Safe mode. Which presumably means we got a function pointer to the managed method (ReturnAsOutString) instead of a n2m wrapper.

Separately the interpreter has some warnings about mismatching stack types

FunctionPointerTests.InvokedAfterGC: Store local stack type mismatch 1 7

but I can't tell yet if that's related to any failure or if it's benign.

lambdageek commented 3 years ago 
 ~/work/dotnet-runtime/runtime/artifacts/bin/DllImportGenerator.Tests/net7.0-Release ~/work/dotnet-runtime/runtime/src/libraries/System.Runtime.InteropServices/tests/DllImportGenerator.Tests
    Discovering: DllImportGenerator.Tests (method display = ClassAndMethod, method display options = None)
    Discovered:  DllImportGenerator.Tests (found 94 test cases)
    Starting:    DllImportGenerator.Tests (parallel test collections = on, max threads = 12)
    Finished:    DllImportGenerator.Tests
  === TEST EXECUTION SUMMARY ===
     DllImportGenerator.Tests  Total: 206, Errors: 0, Failed: 0, Skipped: 0, Time: 0.264s
  ~/work/dotnet-runtime/runtime/src/libraries/System.Runtime.InteropServices/tests/DllImportGenerator.Tests

That's with the JIT (and presumably AOT will be ok, too, given the issue). But the interpreter is very unhappy.

An error has occured in the native fault reporting. Some diagnostic information will be unavailable.
lambdageek commented 3 years ago

Ah ok, in the interpreter, RuntimeMethodHandle.GetFunctionPointer(IntPtr) is an intrinsic that translates to MINT_LDFTN_DYNAMIC which doesn't have a special case for UnmanagedCallersOnly methods. So it returns a pointer to an imethod_to_ftnptr (either an InterpMethod* or a MonoFtnDesc*), not an interp entry point.

lambdageek commented 3 years ago

With #60200, the DllImportGenerator.Tests suite passes for me on desktop (macOS) MonoVM with both the JIT or the interpreter.