.Net 5.0 RC-1 breaks ImageSharp

[lofcz]

Prerequisites

• [x] I have written a descriptive issue title
• [x] I have verified that I am running the latest version of ImageSharp
• [x] I have verified if the problem exist in both DEBUG and RELEASE mode
• [x] I have searched open and closed issues to ensure it has not already been reported

Description

I've encountered a strange bug when mutating images after migrating mvc app from net fw48 to net5 rc1. I've swapped to async image handling. Steps I do (async action on a controller):

1) await HttpContext.Request.ReadFormAsync()
2) Image<Rgba32> img = Image.Load<Rgba32>([first image from form].OpenReadStream(), out IImageFormat imgFormat);
3) await img.SaveAsync("some path"); // saves the image correctly
4) img.Mutate(x => x.Resize(w, h, s)); // thumbnail; used Bicubic, tried Lancoz3 to check if that could be the problem
5) await img.SaveAsync("thumbnail path");

// also tried alternative
5) await using FileStream stream = System.IO.File.Create("some path");
6) await img.SaveAsync(stream, imgFormat);

Extremely frustrating is that this is happening only on production, not on my local machine. I've tried to use another sampler and use latest dev build of ImageSharp, neither helped. In each and every case the first half of an image is mutated correctly, while the other is either blank or filled with artifacts. I'm clueless about how should I move forward, the only option so far would be to go back to sync processing of images which I'd very much like to avoid. Attaching some test images:

Saved thumbnail 1:

Saved non-mutated image 1:

Saved thumbnail 2:

Saved non-mutated image 2:

Saved thumbnail 3:

Saved non-mutated image 3:

System Configuration

• dev: windows 10 20206_rsprerelease, net5 rc1
• production: windows server 2016 datacenter 10.0.14393, net5 rc1

ImageSharp version:

• tried 1.1, then 1.0.2 alpha 7

[klogeaage]

The difference between the 2 skus mentioned by @klogeaage is not just memory size but also CPU constraints. Based on the memory looks like we are talking about a 'B1' scale machine and a 'P2V2' the difference on those machines is not just memory by a move from approx. 1 cpu to something more like 4.

Yes, indeed, you have deducted it absolutely right. So glad we are narrowing this down to something meaningful.

[tannergooding]

We've got some people on the runtime team that are going to look further: https://github.com/dotnet/runtime/issues/42912

For future reference, we don't strictly need a minimal repro on dotnet/runtime for an issue to be opened. We'd much rather get an issue opened than not see it all, especially when we are this late in the release cycle 😄

This might be a more complex runtime bug, in which case finding a minimal repro might be difficult or impossible.

[tocsoft]

@tannergooding Oh thanks for raising that I was planning to it myself one I had reduced it a little more.

[tredition]

A short info: It seems that it doesn't have to do anything with cropping, resizing etc. Just tried out: Simply open a jpg image and save it -> Broken in an Azure App Service (Windows):

            var image = Image.Load<Rgba32>(filename);
            image.Save(filename);

[tocsoft]

it definitely the JPEG decoder that's failing I've updated my reproduction repo to verify that's the case. https://github.com/tocsoft/Net5CorruptingImageSharp

[brianpopow]

good news: It looks like with .Net 5.0 RC-2 this issue will be fixed!

[Sergio0694]

@JimBobSquarePants .NET 5 RC2 is out! 🚀🚀🚀

[brianpopow]

I have tested this issue again with RC2 and can confirm the issue is gone. I will close the issue now.

Thanks to all who helped tracking down this issue!