This was slowly driving me insane while debugging a test which tests shoving a null in a place where it doesn't belong.
Minimal repro:
ClangSharp.Pathogen.LibClangSharpResolver.VerifyResolverWasUsed();
object o = null!;
Console.WriteLine(o.GetHashCode());
You would expect o.GetHashCode to throw NullReferenceException, but on Linux this will throw SEHException instead.
As a workaround you can set LIBCLANG_DISABLE_CRASH_RECOVERY=1, which seems to indicate there's a conflict between Clang's crash recovery and .NET's internal handling of null dereferences.
The easiest workaround would be to use setenv before initializing libclang as suggested here: dotnet/ClangSharp#167 (comment)
This was slowly driving me insane while debugging a test which tests shoving a null in a place where it doesn't belong.
Minimal repro:
You would expect
o.GetHashCodeto throwNullReferenceException, but on Linux this will throwSEHExceptioninstead.As a workaround you can set
LIBCLANG_DISABLE_CRASH_RECOVERY=1, which seems to indicate there's a conflict between Clang's crash recovery and .NET's internal handling of null dereferences.The easiest workaround would be to use
setenvbefore initializing libclang as suggested here: dotnet/ClangSharp#167 (comment)