Imageprocessor: OutOfMemoryExceptions out of nowhere

Created on 11 Jul 2019  路  6Comments  路  Source: JimBobSquarePants/ImageProcessor

TLDR;

Switching to 64 bit mode helped, but that could be a coincidence. It wasnt trowing exceptions for almost a year, so I wonder why we had to switch to 64bit.

Prerequisites

  • [x] I have written a descriptive issue title
  • [x] I have verified that I am running the latest version of ImageProcessor
  • [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

Might be related to: https://github.com/JimBobSquarePants/ImageProcessor/issues/472

Also this tweet encouraged me to open an issue. If there are memory leaks, it seems our code is hitting one.

Regarding testing both DEBUG and RELEASE mode. Locally it doesnt happen, it just happens after pushing to azure.

Description

Publishing a release to azure yieds this (taken from application insights) :

System.OutOfMemoryException:
   at System.Reflection.AssemblyName.nGetFileInformation (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Reflection.AssemblyName.GetAssemblyName (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at ImageProcessor.Common.Helpers.TypeFinder.GetAllAssemblies (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Common.Helpers.TypeFinder.GetFilteredAssemblies (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Common.Helpers.TypeFinder.GetAssembliesWithKnownExclusions (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper.LoadSupportedImageFormats (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper..ctor (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper+<>c.<.cctor>b__19_0 (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at System.Lazy`1.CreateValue (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Lazy`1.LazyInitValue (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Lazy`1.get_Value (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper.get_Instance (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.Helpers.ImageHelpers.BuildExtensionRegexPattern (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.Helpers.ImageHelpers..cctor (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)

System.TypeInitializationException:
   at ImageProcessor.Web.Helpers.ImageHelpers.IsValidImageExtension (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.Services.LocalFileImageService.IsValidRequest (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.HttpModules.ImageProcessingModule+<>c__DisplayClass37_0.<GetImageServiceForRequest>b__0 (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at System.Linq.Enumerable.FirstOrDefault (System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at ImageProcessor.Web.HttpModules.ImageProcessingModule.GetImageServiceForRequest (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.HttpModules.ImageProcessingModule+<ProcessImageAsync>d__31.MoveNext (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Web.TaskAsyncHelper.EndTask (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication+AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication+<>c__DisplayClass285_0.<ExecuteStepImpl>b__0 (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication+StepInvoker.Invoke (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication+StepInvoker+<>c__DisplayClass4_0.<Invoke>b__0 (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at Microsoft.AspNet.TelemetryCorrelation.TelemetryCorrelationHttpModule.OnExecuteRequestStep (Microsoft.AspNet.TelemetryCorrelation, Version=1.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.HttpApplication+<>c__DisplayClass284_0.<OnExecuteRequestStep>b__0 (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication+StepInvoker.Invoke (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication.ExecuteStepImpl (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication.ExecuteStep (System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
Inner exception System.OutOfMemoryException handled at ImageProcessor.Web.Helpers.ImageHelpers.IsValidImageExtension:
   at System.Reflection.AssemblyName.nGetFileInformation (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Reflection.AssemblyName.GetAssemblyName (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at ImageProcessor.Common.Helpers.TypeFinder.GetAllAssemblies (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Common.Helpers.TypeFinder.GetFilteredAssemblies (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Common.Helpers.TypeFinder.GetAssembliesWithKnownExclusions (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper.LoadSupportedImageFormats (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper..ctor (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper+<>c.<.cctor>b__19_0 (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at System.Lazy`1.CreateValue (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Lazy`1.LazyInitValue (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Lazy`1.get_Value (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at ImageProcessor.Configuration.ImageProcessorBootstrapper.get_Instance (ImageProcessor, Version=2.7.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.Helpers.ImageHelpers.BuildExtensionRegexPattern (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)
   at ImageProcessor.Web.Helpers.ImageHelpers..cctor (ImageProcessor.Web, Version=4.10.0.100, Culture=neutral, PublicKeyToken=null)

Steps to Reproduce

No idea, we use the latest version for about half a year now, and usage is restricted to using the query string api.
Changes to web.config were made to allow bigger file uploads (files itself not processed during upload) so maxRequestLength & requestLimits are set higher.

Changes to packages are:

Microsoft.NETCore.Platforms" version="1.1.1 => 1.1.2
System.Runtime" version="4.3.0 => 4.3.1
System.Net.Primitives" version="4.3.0 => 4.3.1
System.Runtime.Extensions" version="4.3.0 => 4.3.1
And the following packages were added instead of relying on the GAC packages:
System.Buffers
System.Memory
System.Numerics.Vectors
System.Runtime.Caching

System Configuration



Azure app service set to .net v4.7 (32bit)

not enough information provided

All 6 comments

Interesting. I don't think this is related to anything I was referencing in my Tweet - I was talking about non-disposed Image instances during processing.

This code only runs once at startup before any images are loaded. Perhaps the changes in dependencies were responsible.

I'm going to remove the type loader anyway. The cost outweighs the benefits.

FYI I would always run any application that requires image processing in 64 bit. 32 bit severely limits the amount of contiguous memory available for holding uncompressed images.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hey, I have a project which has started to do the same thing. Been fine for years, now we have the exact error you are getting because most of the images are not loading from the cache for some reason.

It seems to only be affecting old images actually. So images that were uploaded more than 365 days ago and cached with a width parameter. It's very weird.

For instance this image - https://www.vr.is/media/4780/iceland_pro_travel-2.jpg?width=390 doesn't seem to be loading from the cache and was created 31-05-2017
But if I change the width parameter to - https://www.vr.is/media/4780/iceland_pro_travel-2.jpg?width=391 a new cache was created and its lightning fast.

Im not really sure if it is anything to do with ImageProcessor or something else but just thought i would share.

If I find a solution I will let you know in-case you have a similar issue.

Hi @marysomerville This doesn't look like the same issue. According to the given stack trace the specific OOME is being thrown by the type loader.

In your case, the cached images will be expiring since they have been stored for 365 (default cache expiration date), however a new cached image should be created automatically. Could you please create a new issue so that we can discuss the symptoms there. Thanks!

@JimBobSquarePants I just upgraded to the latest version of your package and its all good now :)
It might have been related to this issue, not sure really - https://github.com/JimBobSquarePants/ImageProcessor/issues/604
But the cache is working now.

@marysomerville Ah that's great to hear, thanks for checking!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

srdjo picture srdjo  路  6Comments

x2764tech picture x2764tech  路  7Comments

skttl picture skttl  路  5Comments

Leftyx picture Leftyx  路  5Comments

joshua-stewart picture joshua-stewart  路  10Comments