Exception 'System.Runtime.InteropServices.SEHException'

[sunthx]

Goals

I'm using RealmDb with my wpf application . sometimes the database will throw an exception ，I don't know how to reproduce it.

Expected Results

succeed

Actual Results

UnhandledException : System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
   在 Realms.SynchronizationContextEventLoopSignal.EventLoop.<>c__DisplayClass3_0.<Post>b__0(Object _)
   在 System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   在 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   在 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   在 System.Threading.ThreadPoolWorkQueue.Dispatch() 

Steps to Reproduce

I don't know how to reproduce this problem.

Version of Realm and Tooling

• Realm.Database 3.4.0
• Realm.DataBinding 1.2.0
• Win10 1809
• .Netframework 4.6.2

[Jared-Aus]

I get this error when trying to use Realm with xUnit. nUnit doesn't complain however.

[fealebenpae]

Hey @Jared-Aus, can you upload a small project that reproduces the crash?

[Jared-Aus]

XUnitTestProject1.zip

[Jared-Aus]

Hey @Jared-Aus, can you upload a small project that reproduces the crash?

Done. Btw, I haven't noticed any issues in my Xamarin or nUnit projects, however it's possible that xUnit is simply less forgiving than the others.

[fealebenpae]

I was able to reproduce this, thanks.
From what I can see the test passes fine, but during teardown the internal notification machinery crashes. I wasn't able to attach the exception in a debugger, unfortunately. Perhaps it's a quirk of the xUnit runner that we'll need to work around.

[Jared-Aus]

I was able to reproduce this, thanks.
From what I can see the test passes fine, but during teardown the internal notification machinery crashes. I wasn't able to attach the exception in a debugger, unfortunately. Perhaps it's a quirk of the xUnit runner that we'll need to work around.

No problems, and yes, that was my experience too.

[andrewdewaal]

I have the same issue; running a simple test of querying against an empty Realm with an InMemoryConfiguration successfully queries, and then throws an SEHException:

 Message: 
    System.Runtime.InteropServices.SEHException : External component has thrown an exception.
  Stack Trace: 
    <>c__DisplayClass3_0.<Post>b__0(Object _)

Has anyone found a fix to put in the teardown to allow for writing xUnit tests with Realm?

[Silic0nS0ldier]

I've hit the same issue with xUnit. As others have observed the test cases run fine, but once done the issue manifests 100% of the time.

Message: 
  System.Runtime.InteropServices.SEHException : External component has thrown an exception.
Stack Trace: 
  SynchronizationContextScheduler.scheduler_invoke_function(IntPtr function_ptr)
  <>c__DisplayClass4_0.<Post>b__0(Object _)

From the trace I managed to pinpoint where the exception is raised.

realm-dotnet/Realm/Realm/Native/SynchronizationContextScheduler.cs

Line 71 in 7b77c15

scheduler_invoke_function(function_ptr);

Based on the .NET documentation for the SEHException class, something is going wrong in Realm Core or another native library.

Any SEH exception that is not automatically mapped to a specific exception is mapped to the SEHException class by default.

If able to catch that exception, we'll likely be closer to fixing this.

Version of Realm and Tooling

Realm 5.1.2 (via NuGet)
Win10 20H2
.NET Core 3.1 and .NET 5.0

[IngweLand]

I have just got the same issue. What actually worked for me is when you return async Task in your Fact/Theory instead of void, even if the code inside the test case does not use anything async related.

[nirinchev]

My guess is that the synchronization context that xunit installs by default gets into an invalid state after the test completes, which means that if Realm tries to invoke anything from it, it will fail. This probably works with the async test because the synchronization context it installs for those behaves differently on teardown. We should try to repro and probably wrap the method calls in SynchronizationContextScheduler in try-catch to handle situations like these.