Open Sean4572435243 opened 11 months ago
vargaz
commented
11 months ago The assert happens on this line:
gpointer jit_wrapper = NULL;
if (need_wrapper) {
MonoMethod *wrapper = mini_get_gsharedvt_out_sig_wrapper (sig);
jit_wrapper = mono_jit_compile_method_jit_only (wrapper, error);
-> mono_error_assert_ok (error);
}
ghost
commented
11 months ago Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
| Author: | Sean4572435243 |
|---|---|
| Assignees: | - |
| Labels: | `arch-wasm`, `untriaged`, `needs-area-label`, `os-browser` |
| Milestone: | - |
Sean4572435243
commented
11 months ago I should've mentioned that I'm publishing from the command line using the following: dotnet publish /p:Configuration=%ConfigurationName% /p:PublishDir=%localDevIISPublishDir% %SolutionDir%\MyApp -p:RunAOTCompilation=true
vargaz
commented
11 months ago Could you run you app with the 'MONO_LOG_LEVEL' env variable set to 'debug' ? You can set env variables in blazor by doing:
https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/startup?view=aspnetcore-8.0#configure-the-net-webassembly-runtime
Sean4572435243
commented
11 months ago My code dynamically loads blazor, not the index.html. When I try the following code, it gives me an
Error: Blazor has already started
even though this is the only section of code that tries to start Blazor. Not sure if the autostart property works
let script1 = document.createElement('script');
script1.src = "/_framework/blazor.webassembly.js";
script1.autostart = "false";
script1.onload = function () {
Blazor.start({
configureRuntime: dotnet => {
dotnet.withEnvironmentVariable("MONO_LOG_LEVEL", "debug");
}
});
};
document.body.appendChild(script1);suggestions?
kg
commented
11 months ago Setting src before setting autostart might be causing the load to begin immediately, have you tried setting src last? I also don't see autostart anywhere in https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement so it's possible that attribute does not work. You'll note that in the examples on that MDN page, they set src after inserting the element into the page.
lambdageek
commented
11 months ago autostart is an attribute that Blazor itself reads from the script tag here, it's not an HTML spec attribute:
so you might need to do
const autostartAttribute = document.createAttribute('autostart');
autostartAttribute.value = 'false';
script1.setAttributeNode(autostartAttribute);
...
document.body.appendChild(script1);Thanks @lambdageek, that was it.
With MONO_LOG_LEVEL now set to debug, the additional Chrome DevTools Console-tab logging that came up when running the app after publishing with AOT:true was the following:
[MONO] AOT: module aot-instances is unusable because dependency MyLazyLoadedLibrary is not found.
Since it works fine with AOT: false, I'm not sure how to help debug this. The MyLazyLoadedLibrary is indeed not present, but I don't attempt to load it at this stage and there's no attempt to fetch it shown in the serviceworker logs. It's almost like AOT:true makes it a hard reference instead of lazy, but I'm not sure how it's determining it's not present, nor why the AOT:true version is treating it differently.
Possibly also worth mentioning, I see 4 instances of the following MONO error, but they're always present regardless of AOT setting and doesn't seem to impact the application.
dotnet.runtime.8.0.0.14kkjimq5k.js:3 [MONO] DllImport error loading library '__Internal': ''.
vargaz
commented
11 months ago Not sure how this happens. If an assembly is part of the build, it should be present at runtime as well, so it should be found.
Sean4572435243
commented
11 months ago All references should be found at build time, yes, (and they are), but lazy loaded assemblies don't need to be present in the publish directory until they are manually loaded. I think the key here is to acknowledge that AOT:false and AOT:true produce different behavior on the same code base, which clearly shouldn't happen.
lambdageek
commented
11 months ago @vargaz Blazor supports lazy loading https://learn.microsoft.com/en-us/aspnet/core/blazor/webassembly-lazy-load-assemblies?view=aspnetcore-8.0. I forget - do we support AOT for assemblies loaded with Assembly.Load?
@radical @maraf WasmAppBuilder should probably not try to AOT-compile assemblies that are listed in the BlazorWebAssemblyLazyLoad item group. Or maybe we can AOT compile them without participating in the shared aot instances?
Is there a way for @Sean4572435243 to turn off shared AOT instances? That will at least leave the main app AOT compiled without references to the lazy loaded assembly, I think. Although that may increase the size of the AOT images.
Sean4572435243
commented
11 months ago AOT:true works as expected in 7.0.13, so I'm hesitant to refactor my large codebase in a workaround fashion when I believe the 7.0.13-8.0.0 code delta can probably reveal what broke. Though I can experiment with turning off shared AOT instances if that will help troubleshoot. How do I do this?
lambdageek
commented
11 months ago Though I can experiment with turning off shared AOT instances if that will help troubleshoot. How do I do this?
I think you set <WasmDedup>false</WasmDedup in your csproj.
I believe the 7.0.13-8.0.0 code delta can probably reveal what broke. Though I can experiment with turning off shared AOT instances if that will help troubleshoot.
I think we turned on WasmDedup on by default in 8.0 because otherwise the AOT image sizes were growing too big for some of our benchmarks
Sean4572435243
commented
11 months ago Adding the WasmDedup tag initially appeared to have corrected the AOT issues, but in the end just made things murkier as I'll explain.
As discussed, I added the single WasmDedup tag just under the TargetFramework tag in my blazor app's csproj, as so:
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<WasmDedup>false</WasmDedup>I then published with AOT:true to my local dev IIS, and then also copied these published files to my staging IIS server.
Using the latest Chrome (119.0.6045.200 (Official Build) (64-bit)) on my development laptop, I'm able to successfully load and run the blazor app, both from the local dev IIS and from the staging IIS. This initial success made me think we solved the issue. However, now here's where it gets murky.
I have a staging Windows 10 VM
(Edition Windows 10 Pro
Version 22H2
Installed on 6/13/2022
OS build 19045.3693
Experience Windows Feature Experience Pack 1000.19053.1000.0) that I'll frequently do sanity checks with, and the Chrome version installed there is the same version as what I'm using on my development laptop. Despite the Chrome version symmetry, for some reason if AOT: true is used to publish and I attempt to run the staging IIS Blazor app on the windows 10 VM, I get the app-breaking errors shown further below. To be clear, this is the same exact IIS source, same exact files, same Chrome version, and yet running the AOT-compiled app in windows 10 breaks but the development laptop doesn't. The windows 10 VM had no problems with AOT:true when it was 7.0.13. Also, if I instead publish with AOT:false, now the Windows 10 VM can successfully run the blazor app.
dotnet.runtime.8.0.0.14kkjimq5k.js:3 [MONO] DllImport error loading library '__Internal': ''.
dotnet.runtime.8.0.0.14kkjimq5k.js:3 [MONO] DllImport error loading library '__Internal': ''.
dotnet.runtime.8.0.0.14kkjimq5k.js:3 Uncaught (in promise) at Microsoft.AspNetCore.Components.WebAssembly.Services.DefaultWebAssemblyJSRuntime.__Wrapper_EndInvokeJS_15588484(JSMarshalerArgument* __arguments_buffer)
Error: EndOfStringNotFound LineNumber: 0 | BytePositionInLine: 38.
at Jn (https://mytesturl/_framework/dotnet.runtime.8.0.0.14kkjimq5k.js:3:31614)
at kr (https://mytesturl/_framework/dotnet.runtime.8.0.0.14kkjimq5k.js:3:35529)
at Object.<anonymous> (https://mytesturl/_framework/dotnet.runtime.8.0.0.14kkjimq5k.js:3:179811)
at Object.endInvokeJSFromDotNet (https://mytesturl/_framework/blazor.webassembly.js:1:44925)
at https://mytesturl/_framework/blazor.webassembly.js:1:2967
Jn @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
kr @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
(anonymous) @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
endInvokeJSFromDotNet @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
Promise.then (async)
beginInvokeJSFromDotNet @ blazor.webassembly.js:1
bn @ blazor.webassembly.js:1
(anonymous) @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
Ul @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
$func64254 @ dotnet.native.wasm:0xc9f023
$func69911 @ dotnet.native.wasm:0xdb0ea5
$func9630 @ dotnet.native.wasm:0x28a0c6
$func17491 @ dotnet.native.wasm:0x50028c
$do_jit_call_indirect @ c7cbb3c6:0x56
$func11212 @ dotnet.native.wasm:0x3061d6
$func4970 @ dotnet.native.wasm:0x15b366
$func699 @ dotnet.native.wasm:0x802bf
$func55423 @ dotnet.native.wasm:0xb5b287
$func83132 @ dotnet.native.wasm:0x10783cd
$func84004 @ dotnet.native.wasm:0x10a8c1a
$func35064 @ dotnet.native.wasm:0x903931
$func60671 @ dotnet.native.wasm:0xc23212
$func3760 @ dotnet.native.wasm:0x10f429
$func20140 @ dotnet.native.wasm:0x594437
$func84003 @ dotnet.native.wasm:0x10a85b6
$func84002 @ dotnet.native.wasm:0x10a842a
$func84006 @ dotnet.native.wasm:0x10a8ea1
$func83081 @ dotnet.native.wasm:0x1072eb5
$func60670 @ dotnet.native.wasm:0xc22f1a
$func3759 @ dotnet.native.wasm:0x10f3e6
$func20148 @ dotnet.native.wasm:0x594757
$func83084 @ dotnet.native.wasm:0x10753b0
$func37773 @ dotnet.native.wasm:0x9901f7
$func60671 @ dotnet.native.wasm:0xc23212
$func37776 @ dotnet.native.wasm:0x9909ed
$func90237 @ dotnet.native.wasm:0x11fabb1
$func14207 @ dotnet.native.wasm:0x3e23f0
$func9580 @ dotnet.native.wasm:0x28765f
$func37624 @ dotnet.native.wasm:0x981b58
$func60671 @ dotnet.native.wasm:0xc23212
$func90089 @ dotnet.native.wasm:0x11f395f
$func37115 @ dotnet.native.wasm:0x9658f2
$func37120 @ dotnet.native.wasm:0x966219
$func60671 @ dotnet.native.wasm:0xc23212
$func88768 @ dotnet.native.wasm:0x11b051e
$func87855 @ dotnet.native.wasm:0x117fe8b
$func37143 @ dotnet.native.wasm:0x96a7c3
$func37122 @ dotnet.native.wasm:0x967477
$func22495 @ dotnet.native.wasm:0x64b257
$func60636 @ dotnet.native.wasm:0xc227a2
$func22232 @ dotnet.native.wasm:0x618aba
$func57147 @ dotnet.native.wasm:0xba9313
$func2660 @ dotnet.native.wasm:0xd192c
$func60634 @ dotnet.native.wasm:0xc226a9
$func22494 @ dotnet.native.wasm:0x64b1cd
$func60635 @ dotnet.native.wasm:0xc22788
$func272 @ dotnet.native.wasm:0x72692
$func17491 @ dotnet.native.wasm:0x500279
$do_jit_call_indirect @ c7cbb3c6:0x56
$func11212 @ dotnet.native.wasm:0x3061d6
$func4970 @ dotnet.native.wasm:0x15b290
$func699 @ dotnet.native.wasm:0x802bf
$func55407 @ dotnet.native.wasm:0xb5ac45
$func4698 @ dotnet.native.wasm:0x141026
$func22288 @ dotnet.native.wasm:0x61bcb1
$func8159 @ dotnet.native.wasm:0x23502c
$func19344 @ dotnet.native.wasm:0x574d63
$func5132 @ dotnet.native.wasm:0x172389
$func3237 @ dotnet.native.wasm:0xf2167
$func6379 @ dotnet.native.wasm:0x1b6e5c
$func22476 @ dotnet.native.wasm:0x649e1c
$func3688 @ dotnet.native.wasm:0x10ac8d
$func37138 @ dotnet.native.wasm:0x969c96
$func22495 @ dotnet.native.wasm:0x64b257
$func60636 @ dotnet.native.wasm:0xc227a2
$func22232 @ dotnet.native.wasm:0x618aba
$func57147 @ dotnet.native.wasm:0xba9313
$func2660 @ dotnet.native.wasm:0xd192c
$func60634 @ dotnet.native.wasm:0xc226a9
$func22494 @ dotnet.native.wasm:0x64b1cd
$func60635 @ dotnet.native.wasm:0xc22788
$func272 @ dotnet.native.wasm:0x72692
$func17491 @ dotnet.native.wasm:0x500279
$do_jit_call_indirect @ c7cbb3c6:0x56
$func11212 @ dotnet.native.wasm:0x3061d6
$func4970 @ dotnet.native.wasm:0x15b290
$func699 @ dotnet.native.wasm:0x802bf
$func55407 @ dotnet.native.wasm:0xb5ac45
$func4698 @ dotnet.native.wasm:0x141026
$func22288 @ dotnet.native.wasm:0x61bcb1
$func8159 @ dotnet.native.wasm:0x23502c
$func19344 @ dotnet.native.wasm:0x574d63
$func5132 @ dotnet.native.wasm:0x172389
$func4395 @ dotnet.native.wasm:0x130c1f
$func19404 @ dotnet.native.wasm:0x578756
$func58823 @ dotnet.native.wasm:0xbd26f5
$func69895 @ dotnet.native.wasm:0xdb03fd
$func69439 @ dotnet.native.wasm:0xd976a7
$func69858 @ dotnet.native.wasm:0xdae599
$func1186 @ dotnet.native.wasm:0x90815
$func17491 @ dotnet.native.wasm:0x500279
$do_jit_call_indirect @ c7cbb3c6:0x56
$func11212 @ dotnet.native.wasm:0x3061d6
$func4970 @ dotnet.native.wasm:0x15b366
$func55333 @ dotnet.native.wasm:0xb58f70
$func55054 @ dotnet.native.wasm:0xb51406
$func11210 @ dotnet.native.wasm:0x305c74
$func2617 @ dotnet.native.wasm:0xcf49e
$func10629 @ dotnet.native.wasm:0x2dee35
$Yb @ dotnet.native.wasm:0xb4cfb1
Module._mono_wasm_invoke_method_bound @ dotnet.native.8.0.0.yeegl3ehmw.js:8
kr @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
l.javaScriptExports.complete_task @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
(anonymous) @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
Promise.then (async)
mo @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
(anonymous) @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
(anonymous) @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
Ul @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
$func64254 @ dotnet.native.wasm:0xc9f023
$func37139 @ dotnet.native.wasm:0x96a0c8
$func37138 @ dotnet.native.wasm:0x969b82
$func60671 @ dotnet.native.wasm:0xc23212
$func88785 @ dotnet.native.wasm:0x11b1021
$func37122 @ dotnet.native.wasm:0x96690f
$func60671 @ dotnet.native.wasm:0xc23212
$func37125 @ dotnet.native.wasm:0x9681a4
$func88770 @ dotnet.native.wasm:0x11b05a4
$func83093 @ dotnet.native.wasm:0x1076550
$func60670 @ dotnet.native.wasm:0xc22f1a
$func3759 @ dotnet.native.wasm:0x10f3e6
$func20148 @ dotnet.native.wasm:0x594757
$func34739 @ dotnet.native.wasm:0x8f65bf
$func1125 @ dotnet.native.wasm:0x8e4e8
$func17491 @ dotnet.native.wasm:0x50028c
$do_jit_call_indirect @ c7cbb3c6:0x56
$func11212 @ dotnet.native.wasm:0x3061d6
$func4970 @ dotnet.native.wasm:0x15b366
$func55333 @ dotnet.native.wasm:0xb58f70
$func55054 @ dotnet.native.wasm:0xb51406
$func11210 @ dotnet.native.wasm:0x305c74
$func1337 @ dotnet.native.wasm:0x96b6d
$func16539 @ dotnet.native.wasm:0x4c9232
$func9194 @ dotnet.native.wasm:0x26df91
$func60890 @ dotnet.native.wasm:0xc2b424
$func57154 @ dotnet.native.wasm:0xba988e
$func11691 @ dotnet.native.wasm:0x322dd3
$func11688 @ dotnet.native.wasm:0x322158
$func60804 @ dotnet.native.wasm:0xc28995
$func60885 @ dotnet.native.wasm:0xc2afe4
$func69859 @ dotnet.native.wasm:0xdaebb6
$func1186 @ dotnet.native.wasm:0x90815
$func17491 @ dotnet.native.wasm:0x500279
$do_jit_call_indirect @ c7cbb3c6:0x56
$func11212 @ dotnet.native.wasm:0x3061d6
$func4970 @ dotnet.native.wasm:0x15b366
$func55333 @ dotnet.native.wasm:0xb58f70
$func55054 @ dotnet.native.wasm:0xb51406
$func11210 @ dotnet.native.wasm:0x305c74
$func2617 @ dotnet.native.wasm:0xcf49e
$func10629 @ dotnet.native.wasm:0x2dee35
$Yb @ dotnet.native.wasm:0xb4cfb1
Module._mono_wasm_invoke_method_bound @ dotnet.native.8.0.0.yeegl3ehmw.js:8
kr @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
l.javaScriptExports.call_entry_point @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
Nc @ dotnet.runtime.8.0.0.14kkjimq5k.js:3
callEntryPoint @ blazor.webassembly.js:1
hn @ blazor.webassembly.js:1
await in hn (async)
mn @ blazor.webassembly.js:1
Cn @ blazor.webassembly.js:1
_0x45e1b4.<computed> @ index.js:1
radical
commented
11 months ago @radical @maraf WasmAppBuilder should probably not try to AOT-compile assemblies that are listed in the
BlazorWebAssemblyLazyLoaditem group. Or maybe we can AOT compile them without participating in the shared aot instances?
I thought we were skipping these already from blazor side. Maybe something regressed in the move to wasm.sdk? We should run the lazyloading tests in WBT for aot too.
Sean4572435243
commented
11 months ago It would be a shame not to AOT lazy loaded libraries. Performance increase with AOT is dramatic
Sean4572435243
commented
11 months ago Since it appears adding
<WasmDedup>false</WasmDedup>
to the csproj fixed the issue identified here, should I open a separate issue to deal with 8.0.0 breaking in windows 10 when AOT:true? Or is this likely a Chrome issue?
Sean4572435243
commented
11 months ago Moved the lingering problem to a new bug report here: https://github.com/dotnet/runtime/issues/96004 Given the satisfactory workaround provided in this current issue, I personally don't have a reason to keep this issue open, though a proper fix would be fantastic.
Is there an existing issue for this?
Describe the bug
Upgraded to 8.0 from 7.0.13. Now when publishing with AOT: true, If I then run the app, I get the following errors in the Chrome DevTools Console log
Expected Behavior
In 7.0.13, app performed equally reliably whether AOT true or false when publishing. In 8.0.0, the app works as expected if AOT is false
Steps To Reproduce
I don't have a minimalist example, only my project that works as expected in 7.0.13
Exceptions (if any)
No response
.NET Version
8.0.100
Anything else?
AspNetCore 8.0.0 Microsoft Visual Studio Professional 2022 Version 17.8.1 VisualStudio.17.Release/17.8.1+34316.72 Microsoft .NET Framework Version 4.8.09037
Installed Version: Professional
ASP.NET and Web Tools 17.8.352.38654 ASP.NET and Web Tools
C# Tools 4.8.0-7.23558.1+e091728607ca0fc9efca55ccfb3e59259c6b5a0a C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
NuGet Package Manager 6.8.0 NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/
Razor (ASP.NET Core) 17.8.3.2353105+f0a326f3e15b2370371693a76fd379635387c74d Provides languages services for ASP.NET Core Razor.