Large image dimensions make thumbnail fails and application to restart

[bjarnef]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

12.3.7

Bug summary

On an Umbraco Cloud project using Umbraco v12.3.7 the content editor has uploaded a PNG icon. The icon/file itself wasn't large | 1.89 MB, but the image dimensions was 20833 x 20833 px

I have attached the icon/image here: accomodation.zip

When accessing the folder listview the thumbnail wasn't shown and accessing this folder made the application to restart.

In the log it was showing a lot of these errors:

Delete the file from recycle bin upload throwed an error, but was successfully deleted including the physical file, which seems to cause these errors in log:

Specifics

No response

Steps to reproduce

Uploa the attached image/file to a folder in media archive. The media thumbnail may not be shown in the folder list view or from media picker depending on the memory available.

Expected result / actual result

No response

[github-actions[bot]]

Hi there @bjarnef!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face:

[bjarnef]

@JimBobSquarePants @nul800sebastiaan could Umbraco with ImageSharp try parse meta data from image and maybe by default limit to a max width/height of image during upload?

In this specific case it didn't seem to have enough ressources to process to image and the application restarted each time GetBigThumbnail was requested. After removing the image everything is fine 🙂

Something like this: https://aaronbos.dev/posts/iptc-metadata-csharp-imagesharp

[JimBobSquarePants]

You’re looking for Image.Identify

That will provide you with the image dimensions plus additional metadata without decoding the image pixels.

[bjarnef]

@JimBobSquarePants thanks 😊🙌

@nul800sebastiaan should we check for this here https://github.com/umbraco/Umbraco-CMS/blob/0cf436fa5cb8db5edc92d6b058841fee9d6adfbb/src/Umbraco.Web.BackOffice/Controllers/ImagesController.cs#L92 and return NotFound() or should we handle this on upload?

[Migaroez]

I was not able to reproduce the locally, but a starter umbraco cloud error leads to this when trying to view the uploaded image's thumbnail, which since i uploaded it on the root now makes the site lock up every time i open the media section 🤦

System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
   at System.Runtime.InteropServices.Marshal.AllocHGlobal(IntPtr cb)
   at SixLabors.ImageSharp.Memory.Internals.UnmanagedMemoryHandle.AllocateHandle(Int32 lengthInBytes)
   at SixLabors.ImageSharp.Memory.Internals.UnmanagedMemoryHandle.Allocate(Int32 lengthInBytes)
   at SixLabors.ImageSharp.Memory.Internals.UnmanagedBuffer`1.Allocate(Int32 lengthInElements)
   at SixLabors.ImageSharp.Memory.UnmanagedMemoryAllocator.Allocate[T](Int32 length, AllocationOptions options)
   at SixLabors.ImageSharp.Memory.MemoryGroup`1.Allocate(MemoryAllocator allocator, Int64 totalLengthInElements, Int32 bufferAlignmentInElements, AllocationOptions options)
   at SixLabors.ImageSharp.Memory.UniformUnmanagedMemoryPoolMemoryAllocator.AllocateGroup[T](Int64 totalLength, Int32 bufferAlignment, AllocationOptions options)
   at SixLabors.ImageSharp.Memory.MemoryAllocatorExtensions.Allocate2D[T](MemoryAllocator memoryAllocator, Int32 width, Int32 height, Boolean preferContiguosImageBuffers, AllocationOptions options)
   at SixLabors.ImageSharp.ImageFrame`1..ctor(Configuration configuration, Int32 width, Int32 height, TPixel backgroundColor, ImageFrameMetadata metadata)
   at SixLabors.ImageSharp.ImageFrame`1..ctor(Configuration configuration, Int32 width, Int32 height, TPixel backgroundColor)
   at SixLabors.ImageSharp.ImageFrameCollection`1..ctor(Image`1 parent, Int32 width, Int32 height, TPixel backgroundColor)
   at SixLabors.ImageSharp.Image`1..ctor(Configuration configuration, Int32 width, Int32 height, ImageMetadata metadata)
   at SixLabors.ImageSharp.Formats.Png.PngDecoderCore.InitializeImage[TPixel](ImageMetadata metadata, FrameControl frameControl, Image`1& image)
   at SixLabors.ImageSharp.Formats.Png.PngDecoderCore.Decode[TPixel](BufferedReadStream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoderUtilities.Decode[TPixel](IImageDecoderInternals decoder, Configuration configuration, Stream stream, Func`3 largeImageExceptionFactory, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoderUtilities.Decode[TPixel](IImageDecoderInternals decoder, Configuration configuration, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.Png.PngDecoder.Decode[TPixel](PngDecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.Png.PngDecoder.Decode(PngDecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.SpecializedImageDecoder`1.Decode(DecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoder.<>c__DisplayClass3_0.<DecodeAsync>b__0(Stream s, CancellationToken ct)
   at SixLabors.ImageSharp.Formats.ImageDecoder.<>c__DisplayClass12_0`1.<WithSeekableMemoryStreamAsync>g__PeformActionAndResetPosition|0(Stream s, Int64 position, CancellationToken ct)
--- End of stack trace from previous location ---
   at SixLabors.ImageSharp.Formats.ImageDecoder.CopyToMemoryStreamAndActionAsync[T](DecoderOptions options, Stream stream, Func`4 action, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoder.DecodeAsync(DecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Image.WithSeekableStreamAsync[T](DecoderOptions options, Stream stream, Func`3 action, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Web.FormattedImage.LoadAsync(DecoderOptions options, Stream source)
   at SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware.ProcessRequestAsync(ImageCommandContext imageCommandContext, IImageResolver sourceImageResolver, ImageContext imageContext, Boolean retry)
   at SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware.ProcessRequestAsync(ImageCommandContext imageCommandContext, IImageResolver sourceImageResolver, ImageContext imageContext, Boolean retry)
   at SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware.Invoke(HttpContext httpContext, Boolean retry)
   at Umbraco.Forms.Web.HttpModules.ProtectFormUploadRequestsMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()

So there are a few things that could be argued here. 1) It's a hardware limitation that the core can't know about 2) It's a user error, they should be trained to not upload unnecessary large images based on 1 3) The core handles the mediaUpload, so it should allow for extension points to enhance the behavior so 1 or 2 does not result in system failures.

The only thing we could do something about is the third argument, so I am wondering whether we should provide a FileUpload validator mechanism that lets you validate the content of the stream that will be persisted based on the filetype determined in the PostAddFile method 🤔 It would behave similar to IFileStreamSecurityAnalyzer.

I will take this up team.

Besides this, I still don't understand how the following examine error is being triggered on your end Invalid deletion count: 2 vs docCount=1 🤔

[bjarnef]

@Migaroez

1. It's a hardware limitation that the core can't know about

   • Yes, but based from my investigations processing an image with such large image dimensions requires quite a lot resources and it think it is possible to see the CPU spike in this case. Should it by default use Image.Identify to check dimensions and have a default configuration? At least not try to generate big thumbnail. If there were multiple images in a folder which such dimensions, I guess it could be an issue with even more memory it the folder had 10 images like this.

2. It's a user error, they should be trained to not upload unnecessary large images based on 1

   • Yes, and I am sure most developers have recommendation for content editors, but there it nothing preventing content editors from doing this. The file size isn't large itself, so content editors (who are often non-tech people) would need to know how to check image dimensions. An alternative could be so show an warning to content editor. In most cases there isn't a need to upload image with dimensions (width and/or height > 10000px).

3. The core handles the mediaUpload, so it should allow for extension points to enhance the behavior so 1 or 2 does not result in system failures.

   • I think ideally it would be great to handle this in core and based on starter plan on Umbraco Cloud as (without deeper knowledge) I think there are probably most projects on this plan (or perhaps Standard)?