[NET Core 3.1] Stack overflow error repeat 24047 times: at Internal.TypeSystem.InstantiatedType.IsCanonicalSubtype(Internal.TypeSystem.CanonicalFormKind) #283
Comments
|
Try adding: <ItemGroup>
<IlcArg Include="--verbose" />
<IlcArg Include="--singlethreaded" />
</ItemGroup>to your csproj and run |
Thanks for your suggestion - I did so, but I still get the same thing. It seems the arguments are/were ignored? This is my csproj file: |
|
@MichalStrehovsky I think I may have found something - although maybe not related? Still, a bare console app doesn't compile so I think it may be related. I made a small repro where you can reproduce a similar issue. Maybe it's not compatible with .NET Core 3.1? https://github.com/darkguy2008/dotnet-runtimelab-issue-283 |
The output.log in the repo indicates it did compile, but failed to run linker. Do you have Visual C++ support installed in VS? We need the C runtime libraries. Try |
MichalStrehovsky
added
the
area-NativeAOT-coreclr
|
Hello again :) thanks for your reply!
Yes, I assume I had those installed when I installed Node.js which installs the VS 2017 Build Tools, right? This is a fresh Windows LTSC install. I also have all the runtimes, installed them from here: https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/ . Since I'm mainly developing on .NET Core I'm avoiding the need to have a full VS install on my machine... considering I have the build tools already, it should be enough, right?
Just did. Same output as well. So what I did now is to open a "Developer Command Prompt for VS 2017" and ran the dotnet commands from there. Running it from stock says the target machine (x86) was incompatible (x64) so what I did was to open a normal command prompt and run Interestingly, I decided to run the linker against the file shown in the log and I get this: Edit:
The file is like this: Edit 2: What could be wrong? |
|
Do you have VS2019? Seems like VS2017 will no longer work. See e.g. google/filament#2142 that has the same missing symbols. |
Thanks for your reply! I didn't, so I installed the VS2019 build tools. That helped to compile the console app with CoreRT, so that's one less issue (although unrelated, but it could be helpful to put in the documentation somewhere that the VS2019 Build Tools are required and that the VS2017 Build Tools won't work at all). Now, I managed to find the culprit and I've updated my repo. It seems to be when you import (and use) the Pomelo.EntityFrameworkCore.MySql reference. So you can try to debug using that repo, I managed to reproduce the issue there. Hope this can be useful. I'll be waiting. Thanks! :D |
|
Hello! Any news on this issue? It's still happening :( |
Entity Framework is not compatible with Native AOT: dotnet/efcore#20393. The fix was rejected by the maintainers: dotnet/efcore#20494 . |
|
@jkotas wow, I can't believe that such a fix to an error was rejected like that. I don't get how that PR is unmaintainable when it actually fixes a big problem (and to be honest, I've rarely seen Core's source code and I could understand that code!! (though, I agree it could've been refactored a bit)). I don't think that the .NET team understands the importance of adding CoreRT support to a very important library used in most, if not all, apps that have a database backend, where the native compilation can add a lot of protection to the source code to prying eyes and other people with bad intentions. At least it'll make it harder for them. It's too bad really. I agree that supporting this in 3.1 might not be a good idea, but what about 5.0 ? It has just been released... maybe for 5.1? |
|
So whatever you guys did (if applicable) now, I managed to get the repo app to correctly compile on Linux and Windows, generating a single native .EXE using EF (as of date) I just had to add: And voilá, it worked! I took that idea from here. Interestingly, also suggested by you @MichalStrehovsky : dotnet/corert#7333 (comment) While I'm unaware of the internals, I tried to open it with ILSpy and it didn't work, so that's enough for me :) . I'm leaving the repo open though, as I assume I shouldn't be using that flag and the bug should be fixed... but it works for me :) False alarm though, I applied this fix to the real app I'm working on and it's still happening :( |
|
I've sent another PR dotnet/efcore#24211 which won't reduce the maintainability like dotnet/efcore#20494 to fix this. Hoping that this time they could accept the fix. |
|
FYI dotnet/efcore#24211 has been merged for EF Core 6.0, thanks @hez2010! |
|
@MichalStrehovsky @jkotas I think this can be closed now. |
Thanks @roji and @hez2010 !! Amazing work! So this means it's ready now? Or do we have to wait for a binary release of EF6? Or is this in the preview release? Do I have to build EF myself? Sorry for all the questions but I'm wondering how to test this to at least confirm it can be closed, if possible :) |
|
@darkguy2008 this should go out as part of EF Core 6.0.0-preview2 - but you can start testing it with our daily builds (probably starting tomorrow). It's highly recommended that people give this a thorough test; after all, we're not sure that this was the only instance of infinite generic recursion, or other things that may block AOT. If further issues are raised early enough, we can take hopefully take care of them for the 6.0 release. |
|
@darkguy2008 There're still some type loading related issues, but it can be resolved by creating a |
|
@hez2010 yeah. Note that it's definitely possible to set up lazy loading without the proxies (so this should be fine with AOT), but the proxies are probably something that never will be. On the other hand, we generally discourage lazy loading so I won't get too hung up on it. |
Hey, first of all thanks for this initiative! CoreRT has been great so far and you guys keeping up with it and integrating it into .NET is by far the best (and most expected) feature, as generating native assemblies has been one of my major wishes in .NET! 👍
Now, I get this when using this repo. The same thing also happens if I use the current CoreRT, but it only says it was terminated due to an StackOverflowException, without any details. This means that the bug exists both in CoreRT and RuntimeLab.
Any pointers would be awesome. I'll try to see if I can create a project that has this bug.
Thanks!
The text was updated successfully, but these errors were encountered: