Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blazor: Running Module.malloc too early? #13915

Closed
kg opened this issue Sep 11, 2019 · 5 comments
Closed

Blazor: Running Module.malloc too early? #13915

kg opened this issue Sep 11, 2019 · 5 comments
Assignees
Labels
area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug. feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly
Milestone

Comments

@kg
Copy link
Member

kg commented Sep 11, 2019

Describe the bug

Blazor appears to be potentially invoking emscripten/mono APIs before mono has actually loaded - there's some logic being executed in preRun that chains some callbacks that can call malloc, which will assert and fail. I'm seeing it in my local execution environment. It could have something to do with the fact that I'm testing a newer build of mono, but there aren't any changes that would cause this problem and it appears that blazor is doing something incorrect.

To Reproduce

Steps to reproduce the behavior:

  1. Follow the directions at https://docs.microsoft.com/en-us/aspnet/core/tutorials/build-your-first-blazor-app?view=aspnetcore-3.0
  2. Replace the mono.js + mono.wasm with a recent from-source build

Expected behavior

Something mostly functions

I think the correct behavior here is for the malloc call (and other calls out to emscripten/mono APIs) to be queued to occur after mono has actually started. I'm a little surprised that these callbacks could run this early but I suppose there's no reason they couldn't (unless this is a violation of some obscure promise ordering spec)

Screenshots

image
image

Additional context

kate@reeir-debian2:~/Projects/blazortest$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview9-014004
 Commit:    8e7ef240a5

Runtime Environment:
 OS Name:     debian
 OS Version:  10
 OS Platform: Linux
 RID:         debian.10-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.100-preview9-014004/

Host (useful for support):
  Version: 3.0.0-preview9-19423-09
  Commit:  2be172345a

.NET Core SDKs installed:
  2.2.402 [/usr/share/dotnet/sdk]
  3.0.100-preview9-014004 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview9.19424.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview9-19423-09 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
@kg
Copy link
Member Author

kg commented Sep 11, 2019

Can confirm that with a release mono.js/mono.wasm built from the same source, the app starts - probably because the assertions are stripped in release mode. 🙃

@mkArtakMSFT mkArtakMSFT added the area-blazor Includes: Blazor, Razor Components label Sep 12, 2019
@pranavkm
Copy link
Contributor

We understand that @lewing is going to suggest some changes to Blazor wasm's startup. This should ensure Blazor works better with mono's startup.

@pranavkm pranavkm added this to the blazor-wasm milestone Sep 12, 2019
@pranavkm pranavkm added the task label Sep 12, 2019
@mkArtakMSFT mkArtakMSFT added bug This issue describes a behavior which is not expected - a bug. and removed task labels Nov 6, 2019
@mkArtakMSFT mkArtakMSFT added the feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly label Nov 8, 2019
@mkArtakMSFT
Copy link
Member

@SteveSandersonMS not sure this is just a tracking issue or not, so assigning to you to do what's necessary here.

@pranavkm
Copy link
Contributor

We can reopen this if there's concrete work to do here.

@ghost ghost locked as resolved and limited conversation to collaborators Jul 12, 2020
@pavelsavara
Copy link
Member

I believe this issue was fixed by #46532

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug. feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly
Projects
None yet
Development

No branches or pull requests

5 participants