[wasm] WebAssembly crashes if building with non-Release/Debug build config

[RPGillespie6]

Description

Not actually sure if this is specifically a dotnet issue or a Skia issue, hoping to get some triage help.

Essentially the problem is that you cannot use custom build configurations if using SkiaSharp + WASM or it will mysteriously crash at runtime on SKPaint dispose (after a using block). But it usually doesn't crash right away, it takes around 79 dispose calls in the repro code before the crash:

Reproduction Steps

Repro repo: https://github.com/RPGillespie6/dotnet_skia_wasm_crash

Build with Release build configuration and observe that the code runs to completion. Build with Release_WASM build configuration and observe that the code crashes on SKPaint dispose after 79 iterations. Confirmed this repo reproduces the problem on 2 different PCs (one with Intel i9, one with AMD Ryzen 7).

We use custom build configurations to set different #if flags, so it's kind of annoying to work around. This is why I'm opening an issue with dotnet -- as far as I can tell, my custom config should have identical settings as Release since I used:

But that doesn't seem to be the case. If I use my custom config, I get mysterious runtime crashes.

Expected behavior

Release and Release_WASM build configs to produce identical runtime results

Actual behavior

Release_WASM results in mysterious crash on after 79 Skia object disposals

Regression?

No response

Known Workarounds

Stick to only using Release or Debug build configurations

Configuration

Everything is in here: https://github.com/RPGillespie6/dotnet_skia_wasm_crash/blob/master/WasmOnly.csproj

Other information

No response

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @brzvlad, @kotlarmilos See info in area-owners.md if you want to be subscribed.

[maraf]

@RPGillespie6 Thank you for the report. It seems it is already fixed in .NET 9 previews, but the fix wasn't backported to .NET 8. Can you please try suggested workaround from https://github.com/dotnet/runtime/issues/94939#issuecomment-1839929771 ?

[RPGillespie6]

Thanks, the suggested workaround from the linked comment appears to workaround the issue! We can close this issue. Is there an issue I can follow to track the progress of the backport to .NET 8 (or is backport not planned for .NET 8)?

[maraf]

Let's leave this one open at the moment. I'll update it based on backport plan

[RPGillespie6]

@maraf A few other related issues I've come across:

1. <EmccLinkOptimizationFlag>-lexports.js</EmccLinkOptimizationFlag> breaks AOT builds for us

I get crashes on page load that look like this:

and

2. <EmccLinkOptimizationFlag>-lexports.js</EmccLinkOptimizationFlag> makes AOT builds take 5x as long

With emcc flag:

aot-instances.dll.bc -> aot-instances.dll.o [took 273.62s]

Without emcc flag:

aot-instances.dll.bc -> aot-instances.dll.o [took 50.04s]

If I remove the emcc flag from AOT builds, then I get a bunch of these at runtime:

Since AOT is so much faster than JIT, I'm back to just using Release and Debug build configurations again which seem to work. Deviating from these 2 build configurations seems like a minefield at the moment.

[maraf]

I'm sorry for late reply.

Since AOT is so much faster than JIT, I'm back to just using Release and Debug build configurations again which seem to work. Deviating from these 2 build configurations seems like a minefield at the moment.

Various parts of .NET SDK provide various defaults based Debug/Release configuration. In WebAssembly the property EmccLinkOptimizationFlag has a default value of -O2 for Release builds. Adding might fix the AOT problem.