Imagesharp: How can I build a release version with ImageSharp

[Sniger87]

Hi,

I use ImageSharp alpha7-00031 and ImageSharp.Drawing alpha7-00045 in my own UWP project. When I build it in Debug-Mode all is fine.
When I build it in Release-Mode I get the following Error:

1>C:\Program Files (x86)\MSBuild\Microsoft.NetNative\x86\ilc\IlcInternals.targets(936,5): error : Internal compiler error: The object reference was not set to an object instance.

I am using Microsoft Visual Studio Enterprise 2015, Microsoft.NETCore.UniversalWindowsPlatform 5.2.2 and NETStandard.Library 1.6.1

[vpenades]

Yes, it seems there's an issue with the Net.Native Compiler used by UWP in VS 2015.

The conditions to produce the exception (most of the time a null exception but not always) are these:

• Visual Studio 2015
• Target UWP store application
• Release mode (with .Net.Native compiler enabled)
• x86 target platform
• Intensive use of System.Numeric.Vectors in multiple threads (as ImageSharp does)

If all these conditions meet, sometimes you get weird exceptions.

I first found this bug two months ago in our own project and drove me crazy, finally I reported it to Microsoft and confirmed it was a bug in the compiler, which, apparently, it's been fixed on Visual Studio 2017.

Solutions:

• Avoid using x86 target platform (which is the only one being affected) and debug/deploy x64 exclusively.
• Switch to Visual Studio 2017.

Btw, when I reported this bug to Microsoft, I also told them to keep an eye on ImageSharp, since there where high chances ImageSharp would be affected by this issue too... I recall Matthew from MS popped up here a while ago...

[JimBobSquarePants]

Hi @Sniger87

The readme specifically states VS2017 as a minimum requirement so you really have to use that. As @vpenades correctly states (thanks for that btw 👍 ) don't use 32bit. MS don't support SIMD yet on 32bit platforms but will do when they switch out the jitter as part of the NetStandard 2.0.0 release in a couple of months. So until then performance will be pretty poor.

Hopefully all this is possible for you and makes sense.

Cheers

James

[Sniger87]

Hi @JimBobSquarePants and @vpenades ,

Thanks for the quick help!

Cheers
Sniger

[JimBobSquarePants]

No worries 😄

[mikegoatly]

@vpenades apologies for adding to a closed issue, but was the bug you raised with Microsoft publicly trackable somewhere? As soon as I add ImageSharp code to my UWP project, I'm still getting this null ref exception when compiling to native x86. I'm using the latest VS2017 (15.5.3) and I've even tried the latest preview 15.6.0 Preview 2 with the same results.

Given that targeting all architectures for a UWP build is recommended best practice, it's hard to see how ImageSharp can be effectively used in a UWP app at the moment.

[vpenades]

@mikegoatly As far as I know, no, I reported it through an unofficial channel, and I was told the issue was already solved in the first version of Vs2017... and that was the case since the moment we moved to VS2017 the problem disappeared.

To correctly identify the issue, be sure that you get different results when compiling in 32 and 64 bits... if it fails on both then it's another kind of bug than the reported here.

If it only fails in 32bit and works fine in 64bit, my suggestion is to report it to Microsoft, and carry on developing in 64bit only until they get the fix. This is what we did at the time.

[mikegoatly]

@vpenades Thanks- yeah, I've just done some more investigation and it looks like the problem only manifests itself with the latest beta version of the ImageSharp package.
A simple repro is:

• New project
• add reference to ImageSharp v1.0.0-beta0002
• Create x86 store packages
• Compilation fails

Using ImageSharp 0.9.0 or just compiling x64/ARM does not cause the error to occur.

I'll get an issue raised with Microsoft tonight.

[vpenades]

@mikegoatly notice that this issue is deeply related to this one: #146

If you read it, Matt Whilden suggest to write directly to [email protected] , dunno if it's still the right channel to solve this.

Also I would suggest to create a repo with a small project that reproduces the issue so others can check if it can be reproduced.

[mikegoatly]

Cool, thanks for the pointer @vpenades - I'll do that. I'll also have a play with different versions of the Microsoft.NETCore.UniversalWindowApplication package to see if that provides any more clues.

[mikegoatly]

Repro created and email sent. I'll update here if I hear anything.

[antonfirsov]

If this issue is actually related to multithreading, I wonder if this workaround helps:
C# if (IntPtr.Size == 4) // 32 bit process { Configuration.Default.ParallelOptions.MaxDegreeOfParallelism = 1; }

[mikegoatly]

Ok, a quick update on this: It's a new compiler issue - the team at Microsoft are hoping to get it fixed for the next release.

[vpenades]

@mikegoatly thanks, did you got some insight of the compiler issue?

It's funny to see how imagesharp is prone to hit msbuild compiler bugs... 😂

[JimBobSquarePants]

It's cos we're so cutting edge 😄

[mikegoatly]

The only detail was that it was likely something to do with the use of Memory and Span, so yeah I guess it's the cutting edge element!