search

Skurdt / SK.Libretro

Libretro wrapper written in C# with support for the Unity game engine
MIT License
28 stars 13 forks source link

Crash on retro_deinit #3

Open Skurdt opened 3 years ago

Skurdt commented 3 years ago

Happens for muppen64plus-next, probably other GL cores too.

kafeijao commented 1 year ago 
=================================================================
        Native Crash Reporting
=================================================================
Got a UNKNOWN while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

=================================================================
        Managed Stacktrace:
=================================================================
          at <unknown> <0xffffffff>
          at System.Object:wrapper_native_00007FFAE49301A0 <0x00086>
          at SK.Libretro.HardwareRenderHelperWindow:Dispose <0x0003c>
          at SK.Libretro.HardwareRenderHelperWindow:Dispose <0x00022>
          at SK.Libretro.GraphicsHandler:Dispose <0x0004a>
          at SK.Libretro.Wrapper:StopContent <0x0005a>
          at SK.Libretro.Unity.Bridge:LibretroThread <0x00bba>
          at System.Threading.ThreadHelper:ThreadStart_Context <0x000a5>
          at System.Threading.ExecutionContext:RunInternal <0x001dd>
          at System.Threading.ExecutionContext:Run <0x0002a>
          at System.Threading.ExecutionContext:Run <0x0005a>
          at System.Threading.ThreadHelper:ThreadStart <0x00042>
          at System.Object:runtime_invoke_void__this__ <0x000d5>

Yep, I hit this issue c:

Seems to happen when this invoke is called: https://github.com/Skurdt/SK.Libretro/blob/e55306956a3b13a3533d74ad795c1e5328b9b6d4/Scripts/Graphics/HardwareRenderHelperWindow.cs#L90

Any idea on a workaround/fix?

Skurdt commented 1 year ago

Only way to debug this is to make debug builds of cores and step into the c side in a debugger. The issue is that it's related both to cpu threads and graphics context from what I remember, and it's also not always happening...

_contextDestroy is a function pointer provided by the core, on the frontend side it's basically take it, store it in your own allocated retro_hw_render_callback struct and call on the function pointer without any idea what it's doing ^^

You could ignore the call and see if the core gets unloaded properly. If it is then the core might have called context_destroy itself or it's simply not needed... The easiest way to test the "unload" issues for me was to check if the copied dll (in temp folder) was still present or not. If it's still present, then it means the File.Delete failed and something is still in use somewhere...

kafeijao commented 1 year ago

If I don't call the _contextDestroy the file is still deleted from the temp folder. I guess we're good, thanks!