[WASM AOT] Image.LoadAsync<Rgba32> hangs unless PixelOperations<Rgba32> is directly rooted

[littletoxic]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified the non-AOT and Release AOT behavior
• I have searched open and closed issues to ensure this exact issue has not already been reported

ImageSharp version

4.0.0

Other ImageSharp packages and versions

None

Environment (Operating system, version and so on)

Windows 10.0.26200 x64, Microsoft Edge, Blazor WebAssembly

.NET Framework version

.NET SDK 11.0.100-preview.5.26302.115
WASM workload 11.0.100-preview.5.26302.115

Description

A Release WASM AOT build can hang or trap while decoding into Rgba32 with ImageSharp 4.0.0.

The failure is specific to the Rgba32 pixel specialization in the tested cases:

• Image.LoadAsync<Rgba32> hangs before returning.
• The same RGBA PNG decoded with Image.LoadAsync<Rgb24> completes.
• An RGB PNG decoded with Image.LoadAsync<Rgba32> hangs.
• JPEG, RGB PNG, palette PNG, and grayscale-alpha PNG decoded to their suggested pixel types complete.
• new Image<Rgba32>(...) completes.
• A direct call to PixelOperations<Rgba32>.Instance.FromRgba32Bytes(...) completes.
• Merely adding a reachable direct call to PixelOperations<Rgba32>.FromRgba32Bytes to the app makes the previously hanging Image.LoadAsync<Rgba32> call complete. This looks like the direct call roots an AOT generic instance that otherwise isn't generated.

Before the input stream was buffered into a MemoryStream, the same path failed with:

MONO_WASM: function signature mismatch
RuntimeError: function signature mismatch

Changing the reachable generic code changed the symptom from a signature-mismatch trap to a hang, but the operation still stopped inside Image.LoadAsync.

ImageSharp 3.1.12 completes the same explicit Image.LoadAsync<Rgba32> test on the same SDK. One relevant v3/v4 code change is that PixelOperations<TPixel>.FromRgba32 changed from the instance call dp.FromRgba32(sp) to the static abstract interface call TPixel.FromRgba32(...).

Steps to Reproduce

Use a standalone Blazor WebAssembly app with:

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="11.0.0-preview.5.26302.115" />
  <PackageReference Include="SixLabors.ImageSharp" Version="4.0.0" />
</ItemGroup>

Run this from a button handler using a PNG stream:

using var image = await Image.LoadAsync<Rgba32>(stream);

The 32x32 RGBA PNG used in the original app is:
https://github.com/littletoxic/ImageConverterWasm/blob/main/src/ImageConverter/wwwroot/favicon.png

Publish and serve:

dotnet publish -c Release
dotnet serve --directory .\bin\Release\net11.0\publish\wwwroot

The full application that first exposed the issue is:
https://github.com/littletoxic/ImageConverterWasm

ImageSharp 4's build-time license validation means I cannot include a reusable license in a public minimal repository. I verified the minimal v4 code locally with an open-source license. The ImageSharp 3.1.12 control needs no license and does not reproduce.

Expected behavior

Image.LoadAsync<Rgba32> completes and returns the decoded 32x32 image in a Release WASM AOT build.

Actual behavior

The call either hangs indefinitely or traps with MONO_WASM: function signature mismatch, depending on which related generic calls are reachable in the app.

Workaround

Both of these avoid the observed failure:

1. Decode into Rgb24 when losing alpha is acceptable.
2. Add a reachable direct call before decoding:

var source = new byte[4];
var destination = new Rgba32[1];
PixelOperations<Rgba32>.Instance.FromRgba32Bytes(
    Configuration.Default,
    source,
    destination,
    destination.Length);

The second workaround suggests a missing WASM AOT generic instantiation rather than bad PNG data.

Related issues

• [IOS Xamarin] System.ExecutionEngineException: Attempting to JIT compile method 'void SixLabors.ImageSharp.Formats.Png.PngScanlineProcessor:ProcessRgbScanline<SixLabors.ImageSharp.PixelFormats.Rgba32> #1708 reported an older AOT compiler failing to generate an ImageSharp PNG/Rgba32 specialization and was classified as an upstream compiler issue.
• [wasm][AOT] null function or function signature mismatch - dotnet/runtime#119143 tracks a WASM AOT generic-sharing signature mismatch. The error family is similar, but I have not proven this report has the same root cause.
• Upstream runtime report: [wasm][AOT] Rgba32 decode hangs or traps unless generic pixel operation is directly rooted dotnet/runtime#130545.

Images

https://github.com/littletoxic/ImageConverterWasm/blob/main/src/ImageConverter/wwwroot/favicon.png

---

This issue was investigated and prepared with assistance from OpenAI Codex.

[littletoxic]

Upstream runtime report filed as dotnet/runtime#130545. It includes the Rgba32/Rgb24 controls, ImageSharp 3.1.12 comparison, and the direct PixelOperations<Rgba32>.FromRgba32Bytes rooting workaround.