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

[wasm] Initial emscripten 3.1.30 support #81215

Merged
merged 57 commits into from
Mar 11, 2023

Conversation

radekdoulik
Copy link
Member

@radekdoulik radekdoulik commented Jan 26, 2023

Part of #80784 implementation

@radekdoulik
Copy link
Member Author

It now builds, we need updated icu and thus docker images to be able to run anything yet.

@radekdoulik
Copy link
Member Author

wasm-ld(0,0): error : (NETCORE_ENGINEERING_TELEMETRY=Build) /__w/1/s/.packages/microsoft.netcore.runtime.icu.transport/8.0.0-preview.2.23108.1/runtimes/browser-wasm/native/lib/libicuuc.a(udata.ao): undefined symbol: icudt68_dat

@maraf looks like the undefined icu symbol causes problem with newer emscripten. could you please take a look?

@maraf
Copy link
Member

maraf commented Feb 13, 2023

wasm-ld(0,0): error : (NETCORE_ENGINEERING_TELEMETRY=Build) /__w/1/s/.packages/microsoft.netcore.runtime.icu.transport/8.0.0-preview.2.23108.1/runtimes/browser-wasm/native/lib/libicuuc.a(udata.ao): undefined symbol: icudt68_dat

Emscripten changed a default value of LLD_REPORT_UNDEFINED (to true) in emscripten-core/emscripten#16003

It's an undefined symbol in ICU, because we are not linking in a lib, that should in the end be linked out.
Updated version of emscripten has by default turned on the LLD_REPORT_UNDEFINED .
@radekdoulik
Copy link
Member Author

radekdoulik commented Feb 21, 2023

@radical could you please take a look at problem with certificates on windows build?

##[error]urllib.error.URLError(0,0): error [SSL: (NETCORE_ENGINEERING_TELEMETRY=Build) CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)>

Looks like installing the certifi doesn't help anymore. https://github.com/dotnet/runtime/blob/main/eng/pipelines/mono/update-machine-certs.ps1#L3

urllib.error.URLError : <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)> [D:\a\_work\1\s\src\mono\sample\wasm\browser-advanced\Wasm.Advanced.Sample.csproj]
##[error]urllib.error.URLError(0,0): error [SSL: (NETCORE_ENGINEERING_TELEMETRY=Build) CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)>
D:\a\_work\1\s\src\mono\wasm\build\WasmApp.Native.targets(333,5): error MSB3073: The command "embuilder.bat build MINIMAL" exited with code 1. [D:\a\_work\1\s\src\mono\sample\wasm\browser-advanced\Wasm.Advanced.Sample.csproj]
##[error]src\mono\wasm\build\WasmApp.Native.targets(333,5): error MSB3073: (NETCORE_ENGINEERING_TELEMETRY=Build) The command "embuilder.bat build MINIMAL" exited with code 1.

Build FAILED.```

@@ -325,10 +325,12 @@
<WriteLinesToFile Lines="@(_EmccCFlags)" File="$(_EmccCompileRsp)" Overwrite="true" WriteOnlyWhenDifferent="true" />
<ItemGroup>
<FileWrites Include="$(_EmccCompileRsp)" />
<EmscriptenMinimalBuildEnvVars Include="@(EmscriptenEnvVars)" />
<EmscriptenMinimalBuildEnvVars Include="FROZEN_CACHE=" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Microsoft.NET.Runtime.Emscripten.Cache SDK overrides the WasmCachePath property. If we're unfreezing the cache here does that mean we can overwrite the nuget contents sometimes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do that on purpose IIRC

<!-- warm up the cache -->
<Exec Command="$(_EmBuilder) build MINIMAL" EnvironmentVariables="@(EmscriptenMinimalBuildEnvVars)" StandardOutputImportance="Low" StandardErrorImportance="Low" />
Is that right @radical?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the freezing/build was required before we were shipping the cache package we should probably review the logic there

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to provide more context: the reason for the change itself is that the default value of FROZEN_CACHE proably changed with newer emscripten, and so the warming embuilder build MINIMAL build was now failing, complaining about not being able to update frozen cache.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole does need to be reviewed again. If the workload is installed in non-user-writable location then how does the build behave? How does the FROZEN_CACHE setting affect things? I have opened #83281 .

@radekdoulik
Copy link
Member Author

radekdoulik commented Feb 23, 2023

@lambdageek @vargaz I see these assertion crashes in some tests:

        [wasm test-browser] [19:58:47] info: Application arguments: --run rebuild_flags_Release.dll
        [wasm test-browser] [19:58:47] info: browser: [main] Console websocket connected.
        [wasm test-browser] [19:58:47] fail: [out of order message from the browser]: http://127.0.0.1:33849/dotnet.js 2:201933 Uncaught ExitStatus: Program terminated with exit(1)
        [wasm test-browser] [19:58:47] fail: [out of order message from the browser]: http://127.0.0.1:33849/dotnet.js 2:201659 Uncaught ExitStatus: Program terminated with exit(1)
        [wasm test-browser] [19:58:47] fail: [out of order message from the browser]: http://127.0.0.1:33849/test-main.js 342:0 Uncaught ExitStatus: Program terminated with exit(1)
        [wasm test-browser] [19:58:47] fail: Error: [MONO] * Assertion at /__w/1/s/src/mono/mono/utils/mono-threads.c:514, condition `<disabled>' not met
        [wasm test-browser]                  
        [wasm test-browser]                      at se (http://127.0.0.1:33849/dotnet.js:3:14137)
        [wasm test-browser]                      at ie (http://127.0.0.1:33849/dotnet.js:3:14427)
        [wasm test-browser]                      at wasm_trace_logger (http://127.0.0.1:33849/dotnet.wasm:wasm-function[11526]:0x213fdb)
        [wasm test-browser]                      at eglib_log_adapter (http://127.0.0.1:33849/dotnet.wasm:wasm-function[560]:0x38d8d)
        [wasm test-browser]                      at monoeg_g_logv_nofree (http://127.0.0.1:33849/dotnet.wasm:wasm-function[455]:0x360e6)
        [wasm test-browser]                      at monoeg_assertion_message (http://127.0.0.1:33849/dotnet.wasm:wasm-function[459]:0x36212)
        [wasm test-browser]                      at mono_assertion_message (http://127.0.0.1:33849/dotnet.wasm:wasm-function[461]:0x3625b)
        [wasm test-browser]                      at mono_assertion_message_disabled (http://127.0.0.1:33849/dotnet.wasm:wasm-function[460]:0x3622b)
        [wasm test-browser]                      at mono_thread_info_attach (http://127.0.0.1:33849/dotnet.wasm:wasm-function[697]:0x3d738)
        [wasm test-browser]                      at sgen_client_init (http://127.0.0.1:33849/dotnet.wasm:wasm-function[3494]:0xc848d)
        [wasm test-browser] [19:58:47] warn: program exited (with status: 1), but EXIT_RUNTIME is not set, so halting execution but not exiting the runtime or preventing further async execution (build with EXIT_RUNTIME=1, if you want a true shutdown)
        [wasm test-browser] [19:58:47] warn: MONO_WASM: mono_wasm_load_runtime () failed: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] warn: MONO_WASM: Error in mono_wasm_before_user_runtime_initialized: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] warn: MONO_WASM: onRuntimeInitializedAsync() failed: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] fail: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] fail: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] fail: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] info: WASM EXIT 1
        [wasm test-browser] [19:58:47] dbug: Reached wasm exit
        [wasm test-browser] [19:58:47] info: Waiting to flush log messages with a timeout of 120 secs ..
        [wasm test-browser] [19:58:47] warn: Message processor is not running anymore.

Do you know what it might be? Should this be called in non-threaded build too?

https://github.com/radekdoulik/runtime/blob/d6f6a4ef2d9b4a83bd68bc19f9bd7c8f8510cb52/src/mono/mono/utils/mono-threads.c#L514

@lambdageek
Copy link
Member

@lambdageek @vargaz I see these assertion crashes in some tests:

        [wasm test-browser] [19:58:47] info: Application arguments: --run rebuild_flags_Release.dll
        [wasm test-browser] [19:58:47] info: browser: [main] Console websocket connected.
        [wasm test-browser] [19:58:47] fail: [out of order message from the browser]: http://127.0.0.1:33849/dotnet.js 2:201933 Uncaught ExitStatus: Program terminated with exit(1)
        [wasm test-browser] [19:58:47] fail: [out of order message from the browser]: http://127.0.0.1:33849/dotnet.js 2:201659 Uncaught ExitStatus: Program terminated with exit(1)
        [wasm test-browser] [19:58:47] fail: [out of order message from the browser]: http://127.0.0.1:33849/test-main.js 342:0 Uncaught ExitStatus: Program terminated with exit(1)
        [wasm test-browser] [19:58:47] fail: Error: [MONO] * Assertion at /__w/1/s/src/mono/mono/utils/mono-threads.c:514, condition `<disabled>' not met
        [wasm test-browser]                  
        [wasm test-browser]                      at se (http://127.0.0.1:33849/dotnet.js:3:14137)
        [wasm test-browser]                      at ie (http://127.0.0.1:33849/dotnet.js:3:14427)
        [wasm test-browser]                      at wasm_trace_logger (http://127.0.0.1:33849/dotnet.wasm:wasm-function[11526]:0x213fdb)
        [wasm test-browser]                      at eglib_log_adapter (http://127.0.0.1:33849/dotnet.wasm:wasm-function[560]:0x38d8d)
        [wasm test-browser]                      at monoeg_g_logv_nofree (http://127.0.0.1:33849/dotnet.wasm:wasm-function[455]:0x360e6)
        [wasm test-browser]                      at monoeg_assertion_message (http://127.0.0.1:33849/dotnet.wasm:wasm-function[459]:0x36212)
        [wasm test-browser]                      at mono_assertion_message (http://127.0.0.1:33849/dotnet.wasm:wasm-function[461]:0x3625b)
        [wasm test-browser]                      at mono_assertion_message_disabled (http://127.0.0.1:33849/dotnet.wasm:wasm-function[460]:0x3622b)
        [wasm test-browser]                      at mono_thread_info_attach (http://127.0.0.1:33849/dotnet.wasm:wasm-function[697]:0x3d738)
        [wasm test-browser]                      at sgen_client_init (http://127.0.0.1:33849/dotnet.wasm:wasm-function[3494]:0xc848d)
        [wasm test-browser] [19:58:47] warn: program exited (with status: 1), but EXIT_RUNTIME is not set, so halting execution but not exiting the runtime or preventing further async execution (build with EXIT_RUNTIME=1, if you want a true shutdown)
        [wasm test-browser] [19:58:47] warn: MONO_WASM: mono_wasm_load_runtime () failed: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] warn: MONO_WASM: Error in mono_wasm_before_user_runtime_initialized: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] warn: MONO_WASM: onRuntimeInitializedAsync() failed: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] fail: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] fail: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] fail: {"name":"ExitStatus","message":"Program terminated with exit(1)","status":1}
        [wasm test-browser] [19:58:47] info: WASM EXIT 1
        [wasm test-browser] [19:58:47] dbug: Reached wasm exit
        [wasm test-browser] [19:58:47] info: Waiting to flush log messages with a timeout of 120 secs ..
        [wasm test-browser] [19:58:47] warn: Message processor is not running anymore.

Do you know what it might be? Should this be called in non-threaded build too?

https://github.com/radekdoulik/runtime/blob/d6f6a4ef2d9b4a83bd68bc19f9bd7c8f8510cb52/src/mono/mono/utils/mono-threads.c#L514

@radekdoulik
that's g_assert(&staddr). So mono_threads_platform_get_stack_bounds isn't working correctly for some reason. With threads disabled that calls wasm_get_stack_base which is emscripten_stack_get_end() - did something change about this function so it returns 0 sometimes?

@pavelsavara
Copy link
Member

The linker puts stack at 0 sometime, so just check that the stack size
is not zero.
@radekdoulik
Copy link
Member Author

The emscripten is now setting stack bounds by the linker generated values. The linker now sometimes puts the stack at the beginning of the linear memory, like in one of the wbt tests, when rebuilding with link -O0 flag.

> wa-info.exe -d -f emscripten_stack_init artifacts\bin\Wasm.Build.Tests\Release\net8.0\browser-wasm\wbt\kk2zltlt.suu\bin\Release\net8.0\browser-wasm\AppBundle\dotnet.wasm
(func emscripten_stack_init)
 i32.const 65536
 global.set $__stack_base
 i32.const 0
 i32.const 15
 i32.add
 i32.const -1
 i32.and
 global.set $__stack_end

The dotnet.wasm before rebuild looks like:

> wa-info.exe -d -f emscripten_stack_init artifacts\bin\Wasm.Build.Tests\Release\net8.0\browser-wasm\wbt\kk2zltlt.suu\dotnet.1.wasm
(func emscripten_stack_init)
 i32.const 651712
 global.set $__stack_base
 i32.const 586176
 global.set $__stack_end

The app seems to run fine locally, so I removed the assert checking the beginning of the stack memory area. Let see how it will look on CI.

@@ -37,8 +38,8 @@ export declare interface EmscriptenModule {
_free(ptr: VoidPtr): void;

// this should match emcc -s EXPORTED_RUNTIME_METHODS
print(message: string): void;
printErr(message: string): void;
out(message: string): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will probably break Blazor.

src/mono/mono/utils/mono-threads.c Show resolved Hide resolved
@@ -45,8 +45,8 @@ declare interface EmscriptenModule {
HEAPF64: Float64Array;
_malloc(size: number): VoidPtr;
_free(ptr: VoidPtr): void;
print(message: string): void;
printErr(message: string): void;
out(message: string): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is API breaking change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we consider this API stable?

We can still get the deprecated ones with -sINCOMING_MODULE_JS_API=print,printErr if needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we consider this API stable?

No

We can still get the deprecated ones with -sINCOMING_MODULE_JS_API=print,printErr if needed.

Yes please, I think these 2 are widely enough used even by Uno.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They could be removed from .d.ts but should keep working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we want to be in the business of maintaining unstable emscripten apis that emscripten has dropped long term but we should document the change and short term compat is fine.

src/mono/wasm/runtime/memory.ts Outdated Show resolved Hide resolved
@lewing
Copy link
Member

lewing commented Mar 10, 2023

it's green! 🎊

@radekdoulik radekdoulik marked this pull request as ready for review March 10, 2023 19:53
if [[ "$SCENARIO" == "WasmTestOnNodeJS" || "$SCENARIO" == "wasmtestonnodejs" ]]; then
JS_ENGINE_ARGS="--engine-arg=--stack-trace-limit=1000"
else
JS_ENGINE_ARGS="--engine-arg=--stack-trace-limit=1000 --engine-arg=--experimental-wasm-bigint"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're at it shouldn't we enable SIMD?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not needed here, shouldn't harm though. I can do it in the follow up PR, to avoid more icu/emsdk package switch backs.

@@ -322,10 +323,12 @@
<WriteLinesToFile Lines="@(_EmccCFlags)" File="$(_EmccCompileRsp)" Overwrite="true" WriteOnlyWhenDifferent="true" />
<ItemGroup>
<FileWrites Include="$(_EmccCompileRsp)" />
<EmscriptenMinimalBuildEnvVars Include="@(EmscriptenEnvVars)" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be clearer to rename this to a private name like _EmscriptenEnvVarsForBuildMinimal.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do it in the follow up PR, to avoid more icu/emsdk package switch backs.

@radical
Copy link
Member

radical commented Mar 10, 2023

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@radical radical left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥳 🎉

@lewing
Copy link
Member

lewing commented Mar 11, 2023

Failures are known

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants