Image resizing is crashing our server about twice a week

[DanPatten]

Hey we narrowed down crash dumps on our .net 4.8 app server running Imageflow 0.13.2.

The utility function is in a library using .net standard 2.0, and this is the input function

using (var b = new ImageJob())
{
    await b.BuildCommandString(
         new StreamSource(streamIn, false),
         new StreamDestination(streamOut, false),
         $"width={width}&height={height}&mode={fitMode}&ignore_icc_errors=true&bgcolor={bgcolor}")
         .Finish()
         .SetSecurityOptions(new SecurityOptions().SetMaxFrameSize(FrameSizeLimit))
         .InProcessAsync();
}

I'm getting an error at JobContext.cs

//Unhandled exception at 0x00007FF97035437D (ntdll.dll) in 1_20250106_121706_memory.hdmp: 0xC0000005: Access violation writing location 0x0000000000000008.

var ptr = NativeMethods.imageflow_context_send_json(Handle, new IntPtr(methodPtr), new IntPtr(jsonPtr), new UIntPtr((ulong)utf8Json.Length));

[lilith]

So based off the mem address, it's a null reference of an 8-byte-or-larger struct, which could be the .Net IntPtr... Is that all the stack trace info available?

…

On Mon, Jan 6, 2025, 2:25 PM DanPatten ***@***.***> wrote: Hey we narrowed down crash dumps on our .net 4.8 app server running Imageflow 0.13.2. The utility function is in a library using .net standard 2.0, and this is the input function using (var b = new ImageJob()) { await b.BuildCommandString( new StreamSource(streamIn, false), new StreamDestination(streamOut, false), $"width={width}&height={height}&mode={fitMode}&ignore_icc_errors=true&bgcolor={bgcolor}") .Finish() .SetSecurityOptions(new SecurityOptions().SetMaxFrameSize(FrameSizeLimit)) .InProcessAsync(); } I'm getting an error at JobContext.cs //Unhandled exception at 0x00007FF97035437D (ntdll.dll) in 1_20250106_121706_memory.hdmp: 0xC0000005: Access violation writing location 0x0000000000000008. var ptr = NativeMethods.imageflow_context_send_json(Handle, new IntPtr(methodPtr), new IntPtr(jsonPtr), new UIntPtr((ulong)utf8Json.Length)); — Reply to this email directly, view it on GitHub <#62>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LH3LRZWVWXFLZTFMJWT2JLYD7AVCNFSM6AAAAABUWMZOLSVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43TCNBXGIZTMOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[DanPatten]

That is all the information that I have, the same image can be uploaded again and it works fine which is strange.

[PhilBrammer]

@DanPatten That behavior make it sound like the second time it works, is because of the crash and memory resetting for that buffer.

[lilith]

You said it's a .net 4.8 server but running imageflow server? I'm confused since that isn't supported. Could you share the /imageflow.debug contents with me at ***@***.***?

…

On Tue, Jan 21, 2025, 3:50 PM Phil Brammer ***@***.***> wrote: @DanPatten <https://github.com/DanPatten> That behavior make it sound like the second time it works, is because of the crash and memory resetting for that buffer. — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LH44PAQTPGQ6YQKYS2D2L3FL3AVCNFSM6AAAAABUWMZOLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBVHEYDAMRTGE> . You are receiving this because you commented.Message ID: ***@***.***>

[DanPatten]

You said it's a .net 4.8 server but running imageflow server? I'm confused
since that isn't supported. Could you share the /imageflow.debug contents
with me at @.***?
…

We are migrating our application from net 48 to 6 and used to use imageresizer, since imageflow supports .net standard 2.0, it provides a path for us to migrate (why Microsoft released .net standard) and has worked great for the past 2 years. Where do I get that debug info at?

[lilith]

Via the browser, ex: http://localhost/imageflow.debug

[DanPatten]

We are not using the Imageflow server, we have our own logic that simply uses Imageflow's utils as a library for converting images using the ImageJob shown above so we don't have any debug info on the browser.

[lilith]

Hmm, ok. While that code snippet looks fine, something else seems like it might be going on, since we aren't having any similar issues popping up with Imageflow Server as far as I can tell. First, make sure the Imageflow.NativeRuntime packages are fully updated to the latest prerelease. Second, can you email me the rest of the code you are using?

…

On Wed, Jan 22, 2025, 8:42 AM DanPatten ***@***.***> wrote: We are not using the Imageflow server, we have our own logic that simply uses Imageflow's utils as a library for converting images using the ImageJob shown above so we don't have any debug info on the browser. — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LH6DOXJVP5NFRBBLKWD2L64ABAVCNFSM6AAAAABUWMZOLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGU4DSNZRHA> . You are receiving this because you commented.Message ID: ***@***.***>

[lilith]

Is the process running low on memory when this happens? Is the process running under 32 or 64 bit?

…

On Wed, Jan 22, 2025, 11:37 AM Lilith River ***@***.***> wrote: Hmm, ok. While that code snippet looks fine, something else seems like it might be going on, since we aren't having any similar issues popping up with Imageflow Server as far as I can tell. First, make sure the Imageflow.NativeRuntime packages are fully updated to the latest prerelease. Second, can you email me the rest of the code you are using? On Wed, Jan 22, 2025, 8:42 AM DanPatten ***@***.***> wrote: > We are not using the Imageflow server, we have our own logic that simply > uses Imageflow's utils as a library for converting images using the > ImageJob shown above so we don't have any debug info on the browser. > > — > Reply to this email directly, view it on GitHub > <#62 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAA2LH6DOXJVP5NFRBBLKWD2L64ABAVCNFSM6AAAAABUWMZOLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGU4DSNZRHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[DanPatten]

We are on 64-bit and not running out of memory, we narrowed down the problem: It seems to crash more often when more requests are made to the server, is this function call thread safe?

This is the only logic we use from Imageflow, we take a stream in and the resize it (migrated from ImageResizer). This sits on an API that we use to load an image with a set width/height/fitmode.

We are on the latest version of Imageflow.NativeRuntime

 public async Task<MemoryStream> ResizeImage(Stream streamIn, int? width, int? height, FitMode? fitMode = FitMode.Pad, Color? bgcolor = null)
 {
     var streamOut = new MemoryStream();
     try
     {
         using (var b = new ImageJob())
         {
             await b.BuildCommandString(
                  BufferedStreamSource.BorrowEntireStream(streamIn),
                  new StreamDestination(streamOut, false),
                  $"width={width}&height={height}&mode={fitMode}&ignore_icc_errors=true&bgcolor={bgcolor}")
                  .Finish()
                  .SetSecurityOptions(new SecurityOptions().SetMaxFrameSize(FrameSizeLimit))
                  .InProcessAsync();
         }
     }
     catch (Exception ex)
     {
         // exception logging
     }
     return streamOut;
 }

[lilith]

Every ImageJob is fully isolated. It's extremely hard to track something like this down when there's no stack trace, and I can't reproduce it or correlate other reports.

I've spent a week doing a paranoid refactoring of the codebase to eliminate as much unchecked code as possible, in the hope of somehow removing whatever rare null reference is causing this.

Please switch to 2.1.0-rc01 and let me know if the issue occurs again.

https://www.nuget.org/packages/Imageflow.NativeRuntime.win-x86_64/2.1.0-rc01