Spurious SEHException thrown when debugging a program using ClangSharp on linux

[DCNick3]

Description

(Also tracked at dotnet/ClangSharp#167)
Running a program as simple as

using ClangSharp.Interop;
class Program
{
    static void Main(string[] args)
    {
        var index = CXIndex.Create();
    }
}

with debugger attached results in a System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception. popping out in different places (depends on where do I put a breakpoint). If I put no breakpoint it shows up somewhere in standard library internals.

Program without a debugger runs just fine (which makes think that this is debugger specific issue).

Does not seem to depend on ClangSharp version.

It is reproducible with both Rider and vs code debugger on arch linux and with rider remote debugging connected to debian.

Configuration

dotnet core 3.1.8
arch linux
x86_64

Regression?

Don't really know

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[tommcdon]

@hoyosjs

[gregg-miskelly]

FYI Might be completely unrelated, but 3.1.9 contains a fix for a bug that sounds similar (see dotnet/coreclr#28090).

[DCNick3]

3.1.9 doesn't seem to fix it

[kekekeks]

The issue can be reproduced by P/Invoking void* clang.createIndex(int, int). It's so simple that it literally can't corrupt managed memory due to marshalling misconfiguration.

It reminds me of ChakraCore rewriting signal handlers and causing CoreCLR to segfault on any NullReferenceException in user code.

So the issue might be caused by libclang doing similar stuff.

[DCNick3]

Oh, as far as I know libclang actually does set it's own segfault handlers. It can be disables with LIBCLANG_DISABLE_CRASH_RECOVERY environment variable. Not sure if ClangSharp disables this

Also, see https://reviews.llvm.org/D23662

[tannergooding]

ClangSharp just delegates to libClang which is build and shipped by LLVM, so it uses whatever the default options are.

[kekekeks]

Confirmed, it's some signal handler installed by libclang that breaks .NET Core debugger.

Wrapping createIndex into SignalWorkaround.Run(() => ...) seems to somewhat solve the issue. At least I'm able to wrap CppAst parsing into that and can successfully debug my code afterwards.

public static class SignalWorkaround
    {
        public static T Run<T>(Func<T> cb)
        {
            var signals = new IntPtr[31];
            
            for (var c = 0; c < signals.Length; c++)
            {
                signals[c] = Marshal.AllocHGlobal(1024);
                sigaction(c + 1, IntPtr.Zero, signals[c]);
            }

            T res;
            try
            {
                res = cb();

            }
            finally
            {

                for (var c = 0; c < signals.Length; c++)
                {
                    sigaction(c + 1, signals[c], IntPtr.Zero);
                    Marshal.FreeHGlobal(signals[c]);
                }
            }

            return res;
        }

        [DllImport("libc")]
        private static extern int sigaction(int signum, IntPtr action, IntPtr oldAction);
    }