search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.56k stars 10.05k forks source link

Blazor WebAssembly app fails with emscripten compiler options #37690

Open djsell opened 3 years ago

djsell commented 3 years ago

Describe the bug

Blazor with WebAssembly does not work when attempting to debug applications using emcc compiler options such as ASSERTIONS, STACK_OVERFLOW_CHECK, and SAFE_HEAP.

To Reproduce

https://github.com/djsell/BlazorWasm

$> dotnet publish -c release
$> cd bin/release/net6.0/publish/wwwroot
$> dotnet-serve

Then load in the browser and check console log.

This project is just the Blazor template project + EmccCompileOptimizationFlag property added to the project file.

Exceptions (if any)

blazor.webassembly.js:1 Error: Failed to start platform. Reason: RuntimeError: abort(Assertion failed: native function `malloc` called before runtime initialization) at Error
    at jsStackTrace (dotnet.6.0.0-preview.7.21377.19.js:1513)
    at stackTrace (dotnet.6.0.0-preview.7.21377.19.js:1534)
    at abort (dotnet.6.0.0-preview.7.21377.19.js:1247)
    at assert (dotnet.6.0.0-preview.7.21377.19.js:696)
    at Object._malloc (dotnet.6.0.0-preview.7.21377.19.js:1270)
    at h (blazor.webassembly.js:1)
    at lt (blazor.webassembly.js:1)

Further technical details

ASP.NET Core 6.0.0-preview.7.21378.6 dotnet:

.NET SDK (reflecting any global.json):
 Version:   6.0.100-preview.7.21379.14
 Commit:    22d70b47bc

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.5
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/sdk/6.0.100-preview.7.21379.14/

Host (useful for support):
  Version: 6.0.0-preview.7.21377.19
  Commit:  91ba01788d

.NET SDKs installed:
  3.1.409 [/usr/local/share/dotnet/sdk]
  5.0.100 [/usr/local/share/dotnet/sdk]
  5.0.203 [/usr/local/share/dotnet/sdk]
  6.0.100-preview.5.21302.13 [/usr/local/share/dotnet/sdk]
  6.0.100-preview.6.21355.2 [/usr/local/share/dotnet/sdk]
  6.0.100-preview.7.21379.14 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.15 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0-preview.5.21301.17 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0-preview.6.21355.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0-preview.7.21378.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.15 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0-preview.7.21377.19 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

VS Code:

Version: 1.59.1
Commit: 3866c3553be8b268c8a7f8c0482c0c0177aa8bfa
Date: 2021-08-19T11:53:52.479Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Darwin x64 20.6.0
djsell commented 3 years ago

I had more info in the readme for my test project. I'll add it here.

The problem with using ASSERTIONS is that Blazor does not use Module.onRuntimeInitialized to run initialization at the correct time.

https://emscripten.org/docs/porting/Debugging.html#debugging-assertions

https://emscripten.org/docs/getting_started/FAQ.html#how-can-i-tell-when-the-page-is-fully-loaded-and-it-is-safe-to-call-compiled-functions

An example of how Mono uses it: https://github.com/dotnet/runtime/blob/v6.0.0-preview.7.21377.19/src/mono/sample/wasm/browser/runtime.js#L13

javiercn commented 3 years ago

@djsell thanks for contacting us.

If you want to attempt a fix for this, the relevant code is here.

Note that we are "late" in the current release and we will very conservative about taking any fix here for 6.0 unless we absolutely have to. I'll let @pranavkm and @SteveSandersonMS chime in too with their thoughts

ghost commented 3 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

dotnet-issue-labeler[bot] commented 3 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

lewing commented 3 years ago

@pranavkm this is an aspnetcore issue, your platform code calls into emscripten functions before it is supposed to.

lewing commented 3 years ago

see https://github.com/dotnet/aspnetcore/issues/13915

ghost commented 3 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

pbiggar commented 3 years ago

I'm having the same issue happening with .NET 6 (released version), when using RunAOTCompilation true in a publish+release build.

It does not happen if either:

I also experimented with moving the preRun code to within onRuntimeInitialized, this gets past the malloc assertions but fails with a different assertion failure:

* Assertion at /__w/1/s/src/mono/mono/metadata/assembly.c:3096, condition `' not met   | 13466314 | @ | dotnet.6.0.0.epfcsc29vy.js:1424   | _emscripten_asm_const_int | @ | dotnet.6.0.0.epfcsc29vy.js:5422   | $func165895 | @ | 2763a776:0x90b38a7   | $func154179 | @ | 2763a776:0x8f46bc8   | $func165098 | @ | 2763a776:0x9092f6e   | $func165096 | @ | 2763a776:0x9092f0c   | $func165101 | @ | 2763a776:0x9092ff3   | $func165103 | @ | 2763a776:0x9093040   | $func165102 | @ | 2763a776:0x909300e   | $func150678 | @ | 2763a776:0x8ede5f5   | $func150540 | @ | 2763a776:0x8ed8f6a   | $func150546 | @ | 2763a776:0x8ed96e5   | $func163918 | @ | 2763a776:0x9069e9c   | $func164124 | @ | 2763a776:0x907115e   | $mono_wasm_load_runtime | @ | 2763a776:0x90b318a   | Module._mono_wasm_load_runtime | @ | dotnet.6.0.0.epfcsc29vy.js:9967   | ccall | @ | dotnet.6.0.0.epfcsc29vy.js:615   | (anonymous) | @ | dotnet.6.0.0.epfcsc29vy.js:635   | (anonymous) | @ | 5284268d-876b-4916-91c3-0f4ef0c798a5:476   | callRuntimeCallbacks | @ | dotnet.6.0.0.epfcsc29vy.js:1436   | postRun | @ | dotnet.6.0.0.epfcsc29vy.js:1143   | doRun | @ | dotnet.6.0.0.epfcsc29vy.js:11619   | run | @ | dotnet.6.0.0.epfcsc29vy.js:11632   | runCaller | @ | dotnet.6.0.0.epfcsc29vy.js:11587   | removeRunDependency | @ | dotnet.6.0.0.epfcsc29vy.js:1216   | receiveInstance | @ | dotnet.6.0.0.epfcsc29vy.js:1351   | (anonymous) | @ | 5284268d-876b-4916-91c3-0f4ef0c798a5:286   | async function (async) |   |     | (anonymous) | @ | 5284268d-876b-4916-91c3-0f4ef0c798a5:277   | module.instantiateWasm

This is blocking my usage of AOT compilation in Blazor, which is an important feature for me.

danwalmsley commented 3 years ago

I'm having the same issue happening with .NET 6 (released version), when using RunAOTCompilation true in a publish+release build.

It does not happen if either:

  • I use build instead of publish
  • I use Debug config instead of Release
  • I set RunAOTCompilation to false.

I also experimented with moving the preRun code to within onRuntimeInitialized, this gets past the malloc assertions but fails with a different assertion failure:

This is blocking my usage of AOT compilation in Blazor, which is an important feature for me.

Exactly the same here!

ghost commented 11 months ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.