Repository navigation
ImageSharp fails to build in Release UWP: invalid method body for CreateFrameQuantizer<TPixel> #828
Description
Prerequisites
- I have written a descriptive issue title
- I have verified that I am running the latest version of ImageSharp
- I have verified if the problem exist in both
DEBUGandRELEASEmode - I have searched open and closed issues to ensure it has not already been reported
Description
As the title says, I can't build an UWP app in Release mode once I reference the ImageSharp library. I've tested both with the .NETCore.UWP package version 6.1.9, 6.2.2 and 6.2.3, none of them worked.
I've also looked at this issue (#198) and only tried to build in x64, but the problem is still there.
These are the two errors I'm getting:
ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-x64.microsoft.net.native.compiler\2.2.1\tools\x64\ilc\Tools\nutc_driver.exe @"C:\Users\Sergi\source\repos\ImageSharpRepro\ImageSharpRepro\obj\x64\Release\ilc\intermediate\MDIL\ImageSharpRepro.rsp"' returned exit code 1
Error: NUTC3033:Internal Compiler Error: Invalid MethodImpl body=6000353 decl=600032d when loading type 'SixLabors.ImageSharp.Processing.Processors.Quantization.PaletteQuantizer
1<TPixel>' from assembly 'SixLabors.ImageSharp' while loading MethodImpl list for 'instance SixLabors.ImageSharp.Processing.Processors.Quantization.IFrameQuantizer1 SixLabors.ImageSharp.Processing.Processors.Quantization.PaletteQuantizer1<TPixel>.SixLabors.ImageSharp.Processing.Processors.Quantization.IQuantizer.CreateFrameQuantizer<TPixel1>(SixLabors.ImageSharp.Configuration)'. while loading type 'SixLabors.ImageSharp.Processing.Processors.Quantization.PaletteQuantizer1'. while computing compilation roots.
As mentioned in the title, the issue is only there in Release mode, while the Debug build works just fine.
Steps to Reproduce
- Create a new UWP project (I'm targeting SDK 17134 and using 16299 as minimum)
- Reference the ImageSharp NuGet package (I'm using version
1.0.0-beta0006) - Try to build the app in Release mode (either x86 or x64), this fails with the errors above
System Configuration
Windows 10 17763.x x64, but I should note I have the same issue on the CI build I have set up for my project, so this doesn't seem to be a problem specific to my configuration.
- ImageSharp version:
- Other ImageSharp packages and versions:
1.0.0-beta0006 - Environment (Operating system, version and so on): Windows 10 17763.x x64
- .NET Framework version: n/a
I'm also going to send a repro to the .NET Native team, in case there's something they can do as well.
Will post an update here as soon as I hear back from them.
Activity
Sergio0694 commentedon Feb 4, 2019
Small update, I received no reply from the .NET Native so far and I've proceeded to open an issue on the CoreRT repo as well (as I believe the .NET Native folks usually monitor that repo).
If anyone else is interested in this issue (am I really the only UWP dev using this lib?), you can follow both issues, the one in CoreRT is right over this message 😄
antonfirsov commentedon Feb 4, 2019
Looks like an AOT compilation issue to me, similar to the mono/Xamarin ones.
I wonder whether the workaround we provided in #767 and #785 helps.
Sergio0694 commentedon Feb 4, 2019
Hey @antonfirsov - thank you for your reply!
I've tried that in my app (I'm only using the
Argb32type, so I just added theAotCompilerTools.Seed<Argb32>()call in my app constructor), but I got the same error 😟I want to note though that as I've mentioned in my first post, the compile error happens even with no code at all that references the library in my app. I mean, as soon as you reference ImageSharp, without actually using it at all, the .NET Native compiler breaks with those errors mentioned above.
I've asked the guys in the CoreRT repo if they can test this with a pre-release build of the upcoming .NETCore.UWP package, which should come out in a couple months or so and should include a new version of the .NET Native compiler, and see if the issue is solved there.
If it isn't, I hope they'll be able to at least provide a workaround at this point 😕
Thank you again for your help!
JimBobSquarePants commentedon Feb 5, 2019
Beginning to really dislike the disconnect between MS dev teams and technologies.
MattWhilden commentedon Feb 5, 2019
Hello! I work on the .NET team and this looks like something we'll need to get investigated. I've cut a bug in our internal bug db (#786375 if that's ever helpful during followup). It's currently assigned to one of the project leads so that it can get routed/triaged/fixed.
I see other ImageSharp issue in our DB that are marked as fixed. Have y'all ever managed to get a version of this building for Release UWP?
Sergio0694 commentedon Feb 6, 2019
Hey @MattWhilden - glad to hear from you again!
I'm happy to hear this is currently being investigated, I'm looking forward to hearing some news about this, or even a possible workaround.
As for your question, this is the first time I've ever used ImageSharp on UWP, but hopefully someone from the ImageSharp team will be able to provide more info on previous attempts to run this combination.
Thank you again for looking into this! 😄
JimBobSquarePants commentedon Feb 6, 2019
@MattWhilden I can't be sure that anyone actually has, in fact, I doubt very much someone has. We have some older issues that I closed due to a lack of support on the UWP side not ours.
MattWhilden commentedon Feb 6, 2019
Appreciate the info. Going in to an investigation know that there may be other lurking things is often quite helpful!
Sergio0694 commentedon Feb 22, 2019
Hey @MattWhilden - any news?
I was wondering if you guys had time to start looking into this and if you managed to find out what is causing the issue. Thanks again! 😄
MattWhilden commentedon Feb 22, 2019
I'll have to follow up with the person working on it and let you know. I don't know that I can catch them today but definitely Monday.
Sergio0694 commentedon Feb 22, 2019
@MattWhilden Sounds great, thank you so much for following up on this, I really appreciate it! 😊
Sergio0694 commentedon Feb 28, 2019
Hey @MattWhilden - sorry to bother, have you heard anything about this?
Any chance a fix for this could be included in the upcoming .NETCore.UWP 6.2.4 package?
Or, I would also be fine with some temporary workaround, maybe some compiler directives to add to the
.rd.xmlfile to make ilc.exe ignore the errors in that specific method (as I'm not using that anyway), if something like this was possible (not sure if the error actually involves multiple files and VS is only showing that one in the output window)?Even knowing an approximate ETA for a fix would help, as right now every single time I want to build a package for the Store I have to go through my code and remove all ImageSharp references, and for this reason I can't proceed to use the library in more places in my app either, as that would make building new packages even more difficult.
cie6868 commentedon Jun 18, 2019
Same bug in my UWP app in release x64 config, but downgrading to
1.0.0-beta0005builds fine.Sergio0694 commentedon Jun 18, 2019
@cie6868 Had no idea downgrading worked, I'll try that, thanks!
Also, FYI this bug has already been fixed by the .NET Native team, so right now we just need them to include it in the next .NETCore.UWP package update. Hopefully it'll be out soon 😕
JimBobSquarePants commentedon Jun 18, 2019
Sigh.... Don’t downgrade, now you’ve introduced 100s of other bugs
20 remaining items
ivanrlg commentedon Aug 28, 2019
Hello again, after a couple of hours trying, cleaning disused packages such as "sqlite-net-pcl", Microsoft.Azure.ActiveDirectory.GraphClient "and" Xam.Plugins.Settings "and changing settings I managed to compile in release mode, I am honestly not sure what the exact cause was that I was generating the compilation error and I am sorry to say it for not being very professional on my part but in the end it has worked. Sorry for the time I have taken from you. @MattWhilden
MattWhilden commentedon Aug 28, 2019
@ivanrlg no worries at all. I'm quite happy to hear you're back on your feet and able to make progress. I have a theory about what your other error could have been so I'll put some extra info here in case it's helpful. If you end up having other .NET Native issues I can be reached directly via dotnetnative@microsoft.com (but I suspect the ImageSharp folks don't mind a bit of back and forth here) 😄
Anyhow, I hope everything else goes smoothly with your development. Certainly let me know if you see anything else that's unexpected. Happy to help!
The Theory
I suspect that the issue from above is that the optimizer (nutc_driver) hit an out of memory condition which failed compilation.
The Clues
The optimizer is the greediest piece of the compiler and this isn't a completely uncommon thing to have happen. You can see me talking about a different circumstance of this kind of error with another developer here. It'll kick out error code '1' for other reasons but this is the most common.
Suggestions
The easiest workaround for most folks is to enable the 64 bit compiled version of nutc_driver.exe. It's available to everyone running on 6.X+ of Microsoft.NETCore.UniversalWindowsPlatform AND a minOSVersion of 16299+. You can enable it by setting this flag in the global properties of your csproj:
<Use64BitCompiler>true</Use64BitCompiler>The linked StackOverflow post has a slightly different issue but setting the optimizer to run as single threaded is another way folks can help reduce memory pressure within the compiler. It's not my preferred way of doing things because it can dramatically increase the amount of time your application takes to build... but if you end up stuck, it's a nice flag to know about.
AwsomeCode commentedon Mar 7, 2020
@MattWhilden Hi, I am getting below error on my UWP build for release mode with ImageSharp Only.
After removing ImageSharp its building fine.
Min SKD Build : 16299
Microsoft.NETCore.UniversalWindowsPlatform : 6.2.9
Using Setting in csproj file :
<Use64Bitcompiler>true</Use64Bitcompiler>AwsomeCode commentedon Mar 7, 2020
@MattWhilden & @JimBobSquarePants
Just to update the progress Its building fine for x64 Release mode but not for the x86 Release mode
JimBobSquarePants commentedon Oct 13, 2020
We need someone to raise an issue upstream here for us to track. We can't fix issues with the AOT compiler.
JimBobSquarePants commentedon Oct 18, 2020
@Sergio0694 Is this still valid? I thought we'd defeated all the UWP build issues?
Sergio0694 commentedon Oct 18, 2020
@JimBobSquarePants The original issue was indeed fixed, you reopened this a while back after @AwsomeCode reported a somewhat related (possibly?) issue. But I can confirm that the original issue here was indeed fixed months ago, yeah 👍
I am using
ImageSharpin one of my apps and it builds just fine in Release x86, x64 and ARM64.JimBobSquarePants commentedon Oct 18, 2020
Sweet. Closing!