[browser][coreCLR] finalizer on a browser event loop

[pavelsavara]

Contributes to #114096

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

This can't be merged right now because enabling finalizer uncovered some memory corruption.

Edit: I commented out the effective piece of code and added TODO-WASM #123712

So that I could merge the code and work with it further on other PRs.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[pavelsavara]

THROWS called in a NOTHROW region.

Log

Assert failure(PID 3368 [0x00000d28], Thread: 1144 [0x0478]): CONTRACT VIOLATION by ManagedThreadBase::KickOff at "D:\a\_work\1\s\src\coreclr\vm\threads.cpp":6033

THROWS called in a NOTHROW region.

                        CONTRACT in ManagedThreadBase::KickOff at "D:\a\_work\1\s\src\coreclr\vm\threads.cpp":6033
VIOLATED-->  CONTRACT in FinalizerThread::FinalizerThreadStart at "D:\a\_work\1\s\src\coreclr\vm\finalizerthread.cpp":562

CORECLR! BaseContract::DoChecks + 0x14A (0x6f3bfcfa)
CORECLR! EEContract::DoChecks + 0x58 (0x6f8e98e8)
CORECLR! ManagedThreadBase::KickOff + 0xBA (0x6f80844a)
CORECLR! FinalizerThread::FinalizerThreadStart + 0x22C (0x6f913c6c)
KERNEL32! BaseThreadInitThunk + 0x24 (0x74ce62c4)
NTDLL! RtlSubscribeWnfStateChangeNotification + 0x439 (0x77de0989)
NTDLL! RtlSubscribeWnfStateChangeNotification + 0x404 (0x77de0954)
    File: D:\a\_work\1\s\src\coreclr\vm\threads.cpp:6033
    Image: C:\h\w\A7630989\p\dotnet.exe

[pavelsavara]

I added NOTHROW contract into FinalizerThread::FinalizerThreadStart because I thought that UNINSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP would always catch any exception.

Looking at the UNINSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP I see that it catches only some exceptions.
catch (PAL_SEHException& ex) and only on Unix.

The failure above is from Windows.

Is my new contract too strict ? Or we need to catch something on Windows too ?

[janvorli]

Right, that macro works only on Unix, because on Windows, the OS itself ensures that the exception is reported as unhandled. On Unix, without that macro, we would get an unhandled PAL_SEHException C++ exception instead, which is not desired.
So for Windows the NOTHROW contract is not correct here. But for Unix, it is actually correct, as all managed exceptions (they are represented by the PAL_SEHException) would be caught there. So we could possibly use the NOTHROW contract for Unix only. Alternatively, we could use the CONTRACT_VIOLATION(ThrowsViolation) in your code that calls this method.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

[pavelsavara]

/ba-g known issues
#123796
#123912