The native AOT DLL library crash failed to generate a dump or catch an exception #92687
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
MichalStrehovsky
added
area-NativeAOT-coreclr
and removed
needs-area-label
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsI used c# native aot to export the library for golang to use. I deliberately write a null pointer access in the library, go server invoke API directly after the crash.I can't find any information related to the crash. I can't find the dump file. [UnmanagedCallersOnly(EntryPoint = "NativeGetLeng")] Why can't catch System.NullReferenceException.
|
|
To make sure I understand the issue correctly: When the above code executes, the Did you try debugging through this in LLDB or GDB? |
|
Exception 0xc0000005 0x0 0x0 0x7ffe2912fee0 runtime.cgocall(0x1556ae4, 0xc000557b90) |
|
Yes, there was no dump. I have not used lldb gdb. |
I assumed this was on Linux, but now I see the Windows file paths. Are you linking the C# code statically (building into a LIB and linking with cgo), or dynamically (C# code is in a DLL that you load at runtime)? |
|
package test //#cgo LDFLAGS: -L./ -lGame -lstdc++ -lm func init() { I develop on windows, I am linking the C# code statically. |
|
Can you try compiling the C# to a DLL and link dynamically? It kind of looks like the golang runtime thinks it's supposed to handle the nullref but then it can't and I'm wondering if linking to a DLL would work around. |
|
Sorry, I made a mistake. I used link dynamically. PS D:\Kit\Crash\CrashGo\bin> ./Debug.exe runtime.cgocall(0xe7ceb8, 0xc00009bf58) goroutine 2 [force gc (idle)]: goroutine 3 [GC sweep wait]: goroutine 4 [GC scavenge wait]: |
|
The reduced repro of the problem (without any Native AOT, just plain C) is this: package main
//static volatile char* Memory;
//
//void* AddVectoredExceptionHandler(unsigned long First, void* Handler);
//void* VirtualAlloc(void* lpAddress, void* dwSize, int flAllocationType, int flProtect);
//int VirtualProtect(void* lpAddress, void* dwSize, int flNewProtect, int* lpflOldProtect);
//
//long VectoredExceptionHandler(void* ExceptionInfo)
//{
// int old;
// VirtualProtect((void*)Memory, (void*)4096, 0x04, &old);
// return 0xffffffff;
//}
//
//int f()
//{
// AddVectoredExceptionHandler(1, &VectoredExceptionHandler);
// Memory = (char*)VirtualAlloc(0, (void*)4096, 0x00001000 | 0x00002000, 0x02);
// *Memory = 42;
// return *Memory;
//}
import "C"
func main() {
C.f()
}The above program installs an exception handler, allocates a piece of read only memory, and tries writing to it. This raises an exception at runtime, but the exception handler enables writing to the memory region and restarts execution. So this function is just a roundabout way to return 42. When invoked from C, or even as a DllImport from Native AOT, this works fine. When invoked from Go however, the Go runtime intercepts the exception and terminates the program. The Go runtime should instead let the called function handle this. There’s nothing we can do about this from .NET side. The bug needs to be fixed in Go. Looks like several people have ran into this already outside of Native AOT. Here’s one issue, but looking through the bug tracker, there are more associated issues about exception handling not working correctly under CGO: golang/go#52763 The bug should not affect regular exception throws in Native AOT, but will affect the ability of catching things like null references, division by zero, integer overflows, and data misalignment exceptions (i.e. exceptions raised by the CPU). |
Cc @AaronRobinsonMSFT in case someone runs into this with DNNE and Golang - knowing this might save you some investigation time. |
|
Thanks @MichalStrehovsky. This is similar to issues we have when the JVM and CoreCLR are in the same process. CoreCLR installs a signal handler and can causing significant disruption with the JVM when trying to handle exceptions. The gist here is loading multiple runtimes, regardless of language, can cause significant and unforeseen issues, particularly where exceptions are involved. |
ghost
locked as resolved and limited conversation to collaborators
I used c# native aot to export the library for golang to use. I deliberately write a null pointer access in the library, go server invoke API directly after the crash.I can't find any information related to the crash. I can't find the dump file.
[UnmanagedCallersOnly(EntryPoint = "NativeGetLeng")]
public static int NativeGetLeng()
{
try
{
List list = new List();
list = null;
return list.Count;
}
catch (System.NullReferenceException e)
{
Log.Info(e.ToString());
return 0;
}
}
Why can't catch System.NullReferenceException.
Is there any way to solve this problem?
The text was updated successfully, but these errors were encountered: