dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.9k stars 4.63k forks source link

Exception in browser when navigating to Blazor page running in InteractiveWebAssembly render mode #104885

Open phantomkingx opened 1 month ago

phantomkingx commented 1 month ago

Is there an existing issue for this?

Describe the bug

Exception in browser when navigating to Blazor page running in InteractiveWebAssembly render mode.

Expected Behavior

No response

Steps To Reproduce

Microsoft Visual Studio Community 2022 (64-bit) - Version 17.10.4 .NET SDK 8.0.303

Created a new blazor web app:

image image

Change the Counter.razor page render mode to InteractiveWebAssembly:

image

Start the app in Visual Studio and navigate to the Counter page: image

Exceptions (if any)

Error: [MONO] /__w/1/s/src/mono/mono/mini/interp/interp.c:3616 at ht (logging.ts:95:18) at Tl (logging.ts:119:27) at dotnet.native.wasm:0xa307 at dotnet.native.wasm:0x3f440 at dotnet.native.wasm:0x3bef4 at dotnet.native.wasm:0x3bfb7 at dotnet.native.wasm:0x3bfea at dotnet.native.wasm:0x1b3c9 at dotnet.native.wasm:0x1d1bd at dotnet.native.wasm:0xe8756

.NET Version

.NET SDK 8.0.303

Anything else?

Edition Windows 11 Pro Version 23H2 Installed on ‎2022-‎10-‎06 OS build 22631.3880 Experience Windows Feature Experience Pack 1000.22700.1020.0

image

Browsers tested: Chrome Version 126.0.6478.127 (Official Build) (64-bit) Firefox Version 128.0

phantomkingx commented 1 month ago

I tried repairing my Visual Studio and no luck. I installing a preview version of Visual Studio as well and same issue.

However when installing Visual Studio 2022 Community in a Windows Sandbox I could not reproduce the issue.

phantomkingx commented 1 month ago

I found the cause which appears to be mentioned in this closed issue https://github.com/dotnet/runtime/issues/98041

It's frustrating that an issue found in February was marked closed even though it still exists, it made finding the existing issue harder to search for. Even though the issue has been fixed in .NET 9, that version is still in preview and not a viable option for most production scenarios so the issue shouldn't be closed until .NET 9 is made stable.

And why wouldn't the fix be ported to .NET 8 which is an LTS version? This is a rather severe issue because it doesn't just break the build, it breaks the entire development environment.

steveisok commented 1 month ago

/cc @lewing

maraf commented 1 month ago

I found the cause which appears to be mentioned in this closed issue https://github.com/dotnet/runtime/issues/98041

I think the issue is different, as the line number in the error differs.

Based on the location in the error it's https://github.com/dotnet/runtime/blob/release/8.0/src/mono/mono/mini/interp/interp.c#L3616, only called from https://github.com/dotnet/runtime/blob/release/8.0/src/mono/mono/mini/interp/interp.c#L7777.

I wasn't able to reproduce the error with matching workload version.

@phantomkingx Can you please try to build the app from command-line with -bl (dotnet build -bl) and share the binlog file? Also, can you please share the build outputs that are producing the error?

phantomkingx commented 1 month ago

I had since fixed my environment by following the steps in the referenced comment https://github.com/dotnet/runtime/issues/98041#issuecomment-1930488327 by cleaning the nuget packages folder.

I found the following steps to reproduce the system wide issue, I'm not sure is all these steps are necessary, but I am including for completeness:

After cleaning the packages folder again and trying to reproduce the system wide issue a second time I was not able to. The published app does still fail on the counter page. I have attached the published application.

publish.zip