Description

When using either DllImport or LibraryImport to call an unmanaged method:

• if the application has been already run at least once, and
• the unmanaged library is modified,

when the application is run again, it will terminate with exit code 137 at the first unmanaged call.

Reproduction Steps

Note that I have only been able to reproduce this on macOS with Arm64 .NET.

Reproduction using small project and script:

1. Unzip the content of PInvokeIssue.zip to a directory
2. run the reproduce-issue.sh script in the directory created above
3. Observe the output (includes demonstration of using dotnet clean as a workaround)

Description of issue:

Using the following C# program:

using System.Runtime.InteropServices;

Console.WriteLine("Before P/Invoke");
NativeFunction();
Console.WriteLine("After P/Invoke");

[DllImport("native")]
static extern void NativeFunction();

an unmanaged library built from the following C code:

#include <stdio.h>

extern __attribute__((visibility("default"))) void NativeFunction()
{
    puts("in native code");
}

and the following build integration in the .csproj file:

    <ItemGroup>
        <None Include="libnative.dylib">
            <CopyToOutputDirectory>Always</CopyToOutputDirectory>
        </None>
    </ItemGroup>

    <Target Name="NativeBuild" BeforeTargets="BeforeBuild">
        <Exec Command="clang -dynamiclib -o libnative.dylib native.c" />
    </Target>

1. Run with dotnet run. Observe three lines of output
2. Modify the unmanaged code, by e.g. replacing "native" with "modified"
3. Run the application again

Expected behavior

You see three lines of output with the middle line modified and an exit code of 0:

Before P/Invoke
in modified code
After P/Invoke

Actual behavior

Only the first line of output is printed, and the application unexpectedly terminates with status code 137:

Before P/Invoke

Regression?

The issue exists also in .NET 6.

Known Workarounds

• Running dotnet with lldb seems avoid the issue
• Using dotnet clean and rebuilding clears the issue
• Reverting the unmanaged library back to its original state causes the application to run normally again.

Configuration

• dotnet version: 7.0.202
• macOS Monterey 12.6.1 (21G217)
• ARM64 (Apple M1 Pro)

The issues doesn't seem to reproduce on Windows or Intel macs.

Other information

With my minimal reproduction, I wasn't able to reproduce the issue by simply replacing the unmanaged library in the build output directory and running again with dotnet path/to/dll. However, with my actual project, even this causes the process to terminate.