Victor

@fizxmike did this code work on 2.4.0 and/or below, and you used it, or is this something you started doing just now?

Basically, I think, Python.NET always assumes, that loaded assemblies are loaded in the full context, meaning reflection only is not currently supported. BTW, it would be more helpful to have...

@danabr if you can reproduce this reliably, can you try to figure out the stack trace for the preceding `GCHandle.Free` call? Or maybe make a test case?

@danabr nvm, I am able to reproduce the issue.

@amos402 this appears to be because `MoveClrInstancesOnwershipToPython` calls `Free` on `GCHandle`, and does not prevent the object from being subsequently finalized.

@danabr this PR has a monkey-patch for the issue that you are experiencing: https://github.com/pythonnet/pythonnet/pull/1260 Unfortunately, I don't have time to produce proper patch. One needs to spend some to understand...

@amos402 @BadSingleton The issue reproduces pretty reliably in https://github.com/losttech/pythonnet/tree/bugs/PythonDerivedCrashFixes . In fact I think to reproduce it one just needs to create a type in Python derived from a .NET...

Honestly, I am not even sure we need `TryComputeArgumentType`. The only thing it provides right now is resolving between `Foo(int)` and `Foo(double)`, which should be handled in a different way...

@hatami57 can you try passing a `Nullable(0.25)` or `Nullable[Double](0.25)` as a workaround?

@akoeplinger I can not reproduce it on a new macOS VM either, but it might be related to `gcc` pointing to `clang`. Let me remove macOS from repro platforms until...