Referencing OpenTK.Mathematics crashes the Ready2Run build. #56971

ChrisKoebke · 2021-08-06T09:36:30Z

Description

When referencing OpenTK.Mathematics (or OpenTK.Windowing.Desktop), I'm getting a NotImplementedException on a Ready2Run publish and the build fails.

Demo project for reproduction:

ConsoleApp1.zip

Steps to reproduce the problem:

Publish the demo project with the following settings:

Configuration

.NET 6
Windows 10
Architecture: x64

Other information

2>ConsoleApp1 -> C:\Users\Win10 Home x64\source\repos\ConsoleApp1\ConsoleApp1\bin\Release\net6.0\win-x64\ConsoleApp1.dll
2>Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
2>C:\Users\Win10 Home x64.nuget\packages\microsoft.netcore.app.crossgen2.win-x64\6.0.0-preview.6.21352.12\tools\crossgen2.exe --targetos:windows
2>--targetarch:x64
2>-O
2>-r:"obj\Release\net6.0\win-x64\linked\OpenTK.Mathematics.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\ConsoleApp1.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Collections.Immutable.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Collections.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.ComponentModel.Primitives.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.ComponentModel.TypeConverter.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Console.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Diagnostics.StackTrace.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Drawing.Primitives.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Drawing.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.IO.Compression.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.IO.MemoryMappedFiles.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.ObjectModel.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Private.CoreLib.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Private.Xml.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Reflection.Metadata.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Runtime.CompilerServices.Unsafe.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Runtime.Extensions.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Runtime.InteropServices.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Runtime.Intrinsics.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Runtime.dll"
2>-r:"obj\Release\net6.0\win-x64\linked\System.Xml.ReaderWriter.dll"
2>--out:"obj\Release\net6.0\win-x64\R2R\OpenTK.Mathematics.dll"
2>obj\Release\net6.0\win-x64\linked\OpenTK.Mathematics.dll
2>
2>Error: The method or operation is not implemented.
2>System.NotImplementedException: The method or operation is not implemented.
2> at Internal.TypeSystem.Ecma.EcmaModule.GetType(String nameSpace, String name, NotFoundBehavior notFoundBehavior) in ILCompiler.TypeSystem.ReadyToRun.dll:token 0x6000573+0x145
2> at Internal.TypeSystem.Ecma.EcmaModule.ResolveTypeReference(TypeReferenceHandle handle) in ILCompiler.TypeSystem.ReadyToRun.dll:token 0x600057c+0x2e
2> at Internal.TypeSystem.Ecma.EcmaModule.EcmaObjectLookupHashtable.CreateValueFromKey(EntityHandle handle) in ILCompiler.TypeSystem.ReadyToRun.dll:token 0x60006d6+0x131
2> at Internal.TypeSystem.LockFreeReaderHashtable2.CreateValueAndEnsureValueIsInTable(TKey key) in ILCompiler.TypeSystem.ReadyToRun.dll:token 0x60003ba+0x0 2> at Internal.TypeSystem.Ecma.EcmaModule.GetObject(EntityHandle handle, NotFoundBehavior notFoundBehavior) in ILCompiler.TypeSystem.ReadyToRun.dll:token 0x6000577+0x0 2> at Internal.TypeSystem.Ecma.EcmaModule.GetType(EntityHandle handle) in ILCompiler.TypeSystem.ReadyToRun.dll:token 0x6000574+0x0 2> at ILCompiler.ReadyToRunCompilationModuleGroupBase.TryGetModuleTokenForExternalType(TypeDesc type, ModuleToken& token) in ILCompiler.ReadyToRun.dll:token 0x60000d4+0x51 2> at ILCompiler.DependencyAnalysis.ReadyToRun.ModuleTokenResolver.GetModuleTokenForType(EcmaType type, Boolean throwIfNotFound) in ILCompiler.ReadyToRun.dll:token 0x60005af+0x3c 2> at ILCompiler.DependencyAnalysis.ReadyToRun.SignatureContext.GetTargetModule(TypeDesc type) in ILCompiler.ReadyToRun.dll:token 0x600061e+0x35 2> at ILCompiler.DependencyAnalysis.ReadyToRun.TypeFixupSignature.GetData(NodeFactory factory, Boolean relocsOnly) in ILCompiler.ReadyToRun.dll:token 0x600065c+0x9 2> at ILCompiler.DependencyAnalysis.ReadyToRunObjectWriter.EmitPortableExecutable() in ILCompiler.ReadyToRun.dll:token 0x6000323+0x174 2> at ILCompiler.ReadyToRunCodegenCompilation.Compile(String outputFile) in ILCompiler.ReadyToRun.dll:token 0x600012f+0x35 2> at ILCompiler.Program.RunSingleCompilation(Dictionary2 inFilePaths, InstructionSetSupport instructionSetSupport, String compositeRootPath, Dictionary2 unrootedInputFilePaths, HashSet1 versionBubbleModulesHash, CompilerTypeSystemContext typeSystemContext) in crossgen2.dll:token 0x600015a+0x5e7
2> at ILCompiler.Program.Run(String[] args) in crossgen2.dll:token 0x6000159+0x52e
2> at ILCompiler.Program.Main(String[] args) in crossgen2.dll:token 0x6000161+0x5

I'm assuming it's this line right here:

runtime/src/coreclr/tools/Common/TypeSystem/Ecma/EcmaModule.cs

Line 322 in 57bfe47

throw new NotImplementedException();

The text was updated successfully, but these errors were encountered:

trylek · 2021-08-10T00:13:01Z

@ChrisKoebke - I have just tried with the latest VS (Version 16.11.0 Preview 4.0 [31605.320.d16.11]) and with the up-to-date RC1 versions of all relevant nuget packages and I cannot repro your problem, publishing the app works fine for me. The pieces are moving pretty fast as we approach the .NET 6 shipping date, could you please give it another shot using the latest bits to make sure we're not chasing the ghost of an issue that has already been fixed?

In general the above error message seems to hint at an internal inconsistency of the framework assemblies but I believe that with a real inconsistency like that all our regular lab testing would be on the floor and we're not observing that. There are also still places in our build system where incrementalism is not perfect so especially if you've been experimenting with building / publishing using different .NET or VS versions I'd strongly suggest trying to clean-rebuild your app.

Thanks

Tomas

ChrisKoebke · 2021-08-11T14:09:41Z

@trylek: Thanks a lot for the detailed reply Tomas! I'm using VS 2022 Version 17.0.0 Preview 2.1 and the "Check for Updates" menu item doesn't seem to let me update to a newer version.

I tried to clean-rebuild the app, but still can't seem to get it working, although the error I'm getting is a different one now:

11/08/2021 16:02:33
System.AggregateException: One or more errors occurred. ---> Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
--- End of inner exception stack trace ---
---> (Inner Exception #0) Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---

Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.

===================

Also getting no stack trace in the output log this time, VS just tells me "something failed, we couldn't determine the cause of the error". Is there anything I can do about the internal inconsistency of framework assemblies in case that's the problem?

Cheers,
Chris

trylek · 2021-08-11T22:35:22Z

Hmm, that sucks, sorry about that. We need to improve the diagnostics for sure. For the time being, the first thing that comes to my mind, would you be willing to try out bumping up MSBuild verbosity? That should produce more build details we can subsequently analyze. In the VS menu bar, Tools | Options, there's this dialog with the tree on the left; under "Projects and Solutions | Build and Run", the bottom half of the detail panel contains two combo boxes, "MSBuild project build output verbosity" and "MSBuild project build log file verbosity"; please try to experiment with switching them to "Normal" or "Detailed", that should yield more info about details of the failure or the point where it happens.

Thanks

Tomas

ChrisKoebke · 2021-08-12T08:49:58Z

Bumped up the MSBuild verbosity to "Normal" and "Detailed", hope that helps:

MsBuild_Detailed.txt
MsBuild_Normal.txt

Cheers,
Chris

trylek · 2021-08-13T18:12:17Z

Hello Chris!

Thanks for sharing the MSBuild logs; using them I finally managed to repro the issue locally. I believe I understand what's going on, how you should be able to work around and what we should fix.

The problem happens in compilation of the method OpenTK.Mathematics.Vector3h.GetObjectData but that doesn't mean there's anything groundbreaking in the method. The method has a System.Runtime.Serialization.StreamingContext parameter; the type itself resides in System.Private.CoreLib (in the framework i.e. outside of your compilation module set) and so a type check fixup is generated.
The interesting bit (and the first Crossgen2 bug) is that the type StreamingContext only ever appears in method signatures in the module, it's never used as a local variable or passed around in the IL code. The Crossgen2 bug is that its internal logic for type harvesting doesn't account for this situation properly and so the type reference (0x01000019 in your case) never makes it to the type resolver table.
As the type StreamingContext is missing in the resolver table, trying to encode its token in the type fixup signature forces us to spin a more complex logic searching the entire compilation module set for a suitable type reference or forwarder to use for encoding the token.
At some point we come to the module System.Runtime.Extensions and search the ExportedTypes within it. I'm not 100% sure but I think that is another Crossgen2 bug, assuming System.Private.CoreLib is not in your compilation module set, System.Runtime.Extensions shouldn't be there either and so I don't see what we're trying to gain by searching it considering we wouldn't be able to use its token anyway.
The super-weird part is that your System.Runtime.Extensions assembly seems to have the ExportedTypes section somehow weirdly malformed. According to its header it claims to be “6.0.0-preview.6.21352.12” and its ExportedTypes section has just 7 entries while normally there should be about 70 forwards as you can see here: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime.Extensions/ref/System.Runtime.Extensions.Forwards.cs; according to history there’s been very little recent churn in the assembly forwarder list so I just cannot see how the version you’re using can have just 7; the fact that the assemblies reside in a folder named “linked” make me think that perhaps the IL linker may have something to do with it. On top of the filtering only 5 out of the 7 ExportedTypes entries are actual forwarders, the remaining two don’t have the IsForwarder flag set. Cc @vitek-karas, @agocke and @MichalStrehovsky to chime in on the linker behavior in the presence of partial facades.
The two final entries without the IsForwarder flag set is what crashes Crossgen2 at

runtime/src/coreclr/tools/Common/TypeSystem/Ecma/EcmaModule.cs

Line 325 in 293c7f6

throw new NotImplementedException();

. @davidwrighton or @MichalStrehovsky might know how to proceed here, it looks like tearing down the compilation just because we were unable to resolve an ExportedType entry seems like a big hammer i.o.w. I would consider removing the throws, perhaps leaving just the TODOs indicating the function can be further improved to implement some obscure cases that no-one is actually using but I think that its incompleteness shouldn’t beat the end developer.
To quickly unblock yourself for now, I would suggest trying to upgrade to Preview 7 or suppressing the IL linker. I believe the primary CG2 bug is not harvesting the signatures of compiled methods for the purpose of reverse type resolution and I’ll do my best to fix that ASAP so that the fix is included in .NET 6 RC1. To further polish the fix we should investigate a potential IL linker bug producing the weird ExportedTypes section and the logic around exported type resolution in CG2 but that may take more time. I have locally verified that a 10 line fix around the harvesting fixes your build.

Thanks

Tomas

trylek · 2021-08-13T18:43:00Z

If upgrading to Preview 7 doesn't fix the issue and disabling the IL linker is not an option for you, you might try to artificially modify the OpenTK.Mathematics assembly to make the type StreamingContext appear somewhere in the IL code e.g. by adding an empty conditional block with a null-check for the parameter in one of the methods with the StreamingContext parameter. This is naturally brittle and should be removed once you're able to switch over to the RC1 hopefully including the fix I'm about to send out the PR for in a minute.

Fixes: dotnet#56971 I believe this is the primary fix for the issue; when a type only ever occurs in method signatures in an assembly, never in the implementation IL, JIT never calls resolveToken for it and so it doesn't make it to the module token resolver table. My investigation revealed additional potential problems in the product around exported type resolution and the IL linker; I described them in the issue thread but I believe this to be both the most appropriate and the safest primary fix. Thanks Tomas

MichalStrehovsky · 2021-08-13T21:29:09Z

@davidwrighton or @MichalStrehovsky might know how to proceed here, it looks like tearing down the compilation just because we were unable to resolve an ExportedType entry seems like a big hammer i.o.w. I would consider removing the throws, perhaps leaving just the TODOs indicating the function can be further improved to implement some obscure cases that no-one is actually using but I think that its incompleteness shouldn’t beat the end developer.

If the IsForwarder bit is not set, this is a multimodule assembly. We could make it into a resolution failure, although this is not that the type wasn't found - it was found, but it's in a different module.

the fact that the assemblies reside in a folder named “linked” make me think that perhaps the IL linker may have something to do with it. On top of the filtering only 5 out of the 7 ExportedTypes entries are actual forwarders, the remaining two don’t have the IsForwarder flag set. Cc @vitek-karas, @agocke and @MichalStrehovsky to chime in on the linker behavior in the presence of partial facades.

Could you attach the binary? IL Linker could have messed it up.

trylek · 2021-08-13T21:35:41Z

Thanks @MichalStrehovsky for your quick response. You can easily find the offending assembly in the zip file shared by Chris in the top post on this thread, in the subfolder ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Runtime.Extensions.dll.

MichalStrehovsky · 2021-08-13T21:53:16Z

Thanks! I missed that one.

ILDASM says they all have the Forwarder bit, so it's a bit of a mystery.

ExportedType #1 (27000001)
-------------------------------------------------------
	Token: 0x27000001
	Name: System.BitConverter
	Implementation token: 0x23000001
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)


ExportedType #2 (27000002)
-------------------------------------------------------
	Token: 0x27000002
	Name: System.IO.BinaryReader
	Implementation token: 0x23000001
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)


ExportedType #3 (27000003)
-------------------------------------------------------
	Token: 0x27000003
	Name: System.IO.BinaryWriter
	Implementation token: 0x23000001
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)


ExportedType #4 (27000004)
-------------------------------------------------------
	Token: 0x27000004
	Name: System.Math
	Implementation token: 0x23000001
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)


ExportedType #5 (27000005)
-------------------------------------------------------
	Token: 0x27000005
	Name: System.MathF
	Implementation token: 0x23000001
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)


ExportedType #6 (27000006)
-------------------------------------------------------
	Token: 0x27000006
	Name: System.Security.Permissions.SecurityAction
	Implementation token: 0x26000000
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)


ExportedType #7 (27000007)
-------------------------------------------------------
	Token: 0x27000007
	Name: System.Security.Permissions.SecurityPermissionAttribute
	Implementation token: 0x26000000
	TypeDef token: 0x00000000
	Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [Forwarder]  (00200000)

trylek · 2021-08-13T21:57:09Z

Hmm, you're definitely much more fluent with ILDASM than I am, I just tried to ildasm SRE.dll /tokens /out=... and I got the following excerpt:

.class extern /*27000001*/ forwarder System.BitConverter
{
  .assembly extern System.Private.CoreLib /*23000001*/ 
}
.class extern /*27000002*/ forwarder System.IO.BinaryReader
{
  .assembly extern System.Private.CoreLib /*23000001*/ 
}
.class extern /*27000003*/ forwarder System.IO.BinaryWriter
{
  .assembly extern System.Private.CoreLib /*23000001*/ 
}
.class extern /*27000004*/ forwarder System.Math
{
  .assembly extern System.Private.CoreLib /*23000001*/ 
}
.class extern /*27000005*/ forwarder System.MathF
{
  .assembly extern System.Private.CoreLib /*23000001*/ 
}
.module System.Runtime.Extensions.dll
// MVID: {494ECFC1-B481-4B56-AC6E-08144C328037}
.custom /*0C000001:0A000010*/ instance void [System.Private.CoreLib/*23000001*/]System.Runtime.CompilerServices.SkipLocalsInitAttribute/*01000012*/::.ctor() /* 0A000010 */ = ( 01 00 00 00 ) 
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000009    //  ILONLY
// Image base: 0x02E80000

// 
//

seemingly indicating that the tool sees a distinction between the first five and the last two entries. One way or another, SecurityAction is the one that's tripping Crossgen2 which doesn't see its Forwarder flag being set.

trylek · 2021-08-13T22:00:30Z

Also, if anyone wanted to try debugging Crossgen2 locally to see the problem described above, this is the response file (naturally modulo local file paths):

--targetos:windows
--targetarch:x64
-O
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\OpenTK.Mathematics.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\ConsoleApp1.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Collections.Immutable.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Collections.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.ComponentModel.Primitives.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.ComponentModel.TypeConverter.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Console.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Diagnostics.StackTrace.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Drawing.Primitives.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Drawing.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.IO.Compression.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.IO.MemoryMappedFiles.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.ObjectModel.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Private.CoreLib.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Private.Xml.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Reflection.Metadata.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Runtime.CompilerServices.Unsafe.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Runtime.Extensions.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Runtime.InteropServices.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Runtime.Intrinsics.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Runtime.dll"
-r:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\System.Xml.ReaderWriter.dll"
--out:"D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\R2R\OpenTK.Mathematics.dll"
D:\triage\TK2\ConsoleApp1\obj\Release\net6.0\win-x64\linked\OpenTK.Mathematics.dll

davidwrighton · 2021-08-13T22:04:25Z

The issue is that to return true for IsForwarder, the implementation token needs to reference an AssemblyRef. If you look at the exported type Implementation token, in the ildasm output you can see that the token is 0x26000000. That indicates a token into the File table with Rid 0. This is nonsense and an indication that the IL Linker did something unfortunate. We should probably fix the code to detect this sort of nonsense and simple not consider that ExportedType token as meaningful, and file a bug against the IL linker to not spit that out.

MichalStrehovsky · 2021-08-13T22:06:28Z

Could we be hitting the other NotImplementedException right above that line? The ImplementationToken on the last two ExportedTypes seems bogus. They are forwarders, but bogus.

Cc @sbomer for type forwards not looking right after trimming. I think this might be related to us not shipping complete closure - IIRC some of the System.Security things by design don't resolve unless one references a NuGet package.

trylek · 2021-08-13T22:15:08Z

I definitely saw us hitting the "lower" throw in the debugger and I think it aligns with David's explanation.

…57366) Fixes: #56971 I believe this is the primary fix for the issue; when a type only ever occurs in method signatures in an assembly, never in the implementation IL, JIT never calls resolveToken for it and so it doesn't make it to the module token resolver table. My investigation revealed additional potential problems in the product around exported type resolution and the IL linker; I described them in the issue thread but I believe this to be both the most appropriate and the safest primary fix. Thanks Tomas

sbomer · 2021-08-17T18:02:28Z

I've confirmed that the issue with the linker writing invalid exports was fixed by dotnet/linker@664e78e.

ChrisKoebke · 2021-09-15T06:42:56Z

Hey all,

I just updated to the newly released RC1 and the R2R build sadly still doesn't work for my app. I opened a new issue (as it's probably a different bug?) here:
#59138

dotnet-issue-labeler bot added area-crossgen2-coreclr untriaged New issue has not been triaged by the area owner labels Aug 6, 2021

trylek added this to the 6.0.0 milestone Aug 9, 2021

trylek removed the untriaged New issue has not been triaged by the area owner label Aug 9, 2021

trylek mentioned this issue Aug 13, 2021

Harvest signatures of methods being compiled by the token resolver #57366

Merged

ghost added the in-pr There is an active PR which will close this issue when it is merged label Aug 13, 2021

ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Aug 13, 2021

trylek closed this as completed in #57366 Aug 14, 2021

ghost removed the in-pr There is an active PR which will close this issue when it is merged label Aug 14, 2021

sbomer self-assigned this Aug 16, 2021

sbomer removed their assignment Aug 17, 2021

ChrisKoebke mentioned this issue Sep 15, 2021

Referencing OpenTK.Graphics crashes the Ready2Run build. #59138

Closed

ghost locked as resolved and limited conversation to collaborators Nov 3, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Referencing OpenTK.Mathematics crashes the Ready2Run build. #56971

Referencing OpenTK.Mathematics crashes the Ready2Run build. #56971

ChrisKoebke commented Aug 6, 2021

trylek commented Aug 10, 2021

ChrisKoebke commented Aug 11, 2021

trylek commented Aug 11, 2021

ChrisKoebke commented Aug 12, 2021

trylek commented Aug 13, 2021

trylek commented Aug 13, 2021

MichalStrehovsky commented Aug 13, 2021

trylek commented Aug 13, 2021

MichalStrehovsky commented Aug 13, 2021

trylek commented Aug 13, 2021

trylek commented Aug 13, 2021

davidwrighton commented Aug 13, 2021

MichalStrehovsky commented Aug 13, 2021

trylek commented Aug 13, 2021

sbomer commented Aug 17, 2021

ChrisKoebke commented Sep 15, 2021

Referencing OpenTK.Mathematics crashes the Ready2Run build. #56971

Referencing OpenTK.Mathematics crashes the Ready2Run build. #56971

Comments

ChrisKoebke commented Aug 6, 2021

Description

Demo project for reproduction:

Steps to reproduce the problem:

Configuration

Other information

trylek commented Aug 10, 2021

ChrisKoebke commented Aug 11, 2021

trylek commented Aug 11, 2021

ChrisKoebke commented Aug 12, 2021

trylek commented Aug 13, 2021

trylek commented Aug 13, 2021

MichalStrehovsky commented Aug 13, 2021

trylek commented Aug 13, 2021

MichalStrehovsky commented Aug 13, 2021

trylek commented Aug 13, 2021

trylek commented Aug 13, 2021

davidwrighton commented Aug 13, 2021

MichalStrehovsky commented Aug 13, 2021

trylek commented Aug 13, 2021

sbomer commented Aug 17, 2021

ChrisKoebke commented Sep 15, 2021