NativeFileReference regression in .NET 8.0

Description

A object detection sample project using the ONNX runtime as WASM static library is running well using NET7.0 but fails on NET8.0rc with the following error chain:

``

await createEmscripten(module);
..
mono_download_assets();
...
}).catch(err => {
loaderHelpers.err("Error in mono_download_assets: " + err);
mono_exit(1, err);
throw err;
});

``

The error comes obviously from the inclusion of the ONNX rumtime.

Reproduction Steps

Clone the repository WASMObjectDetector
Run the WASMObjectDetector7 sample
Run the WASMObjectDetector8 sample

Expected behavior

WASMObjectDetector8 sample working as well.

Actual behavior

WASMObjectDetector8 sample -> failing with "Error in mono_download_assets"

Regression?

working on NET7.0

Known Workarounds

none

Configuration

VS Version 17.8.0 Preview 3.0
NET7.0 SDK 7.0.402
NET8.0rc2 SDK 8.0.100-rc.2.23502.2

Other information

No response

Running the .NET 8 sample (with dotnet-sdk-8.0.100-rc.2.23502.2-win-x64) ~~I'm getting a different error~~
EDIT: It's the same error

Error
    at Object.ke [as mono_exit] (http://localhost:5028/_framework/dotnet.js:3:19020)
    at Ll.e.onAbort.e.onAbort (http://localhost:5028/_framework/dotnet.runtime.8.0.0-rc.2.23479.6.cfr91rytrt.js:3:214072)
    at abort (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:856:22)
    at ___cxx_global_var_init (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:1400:51)
    at __wasm_call_ctors (http://localhost:5028/_framework/dotnet.native.wasm:wasm-function[109]:0x1813d)
    at callRuntimeCallbacks (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:1238:26)
    at initRuntime (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:725:3)
    at doRun (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:7793:5)
    at run (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:7813:5)
    at runCaller (http://localhost:5028/_framework/dotnet.native.8.0.0-rc.2.23479.6.gzw26f0zwy.js:7756:19)

From dotnet.native.js

  /** @type {function(...*):?} */
  function ___cxx_global_var_init(
  ) {
  err('missing function: __cxx_global_var_init'); abort(-1);
  }

The .NET 7 version works

after 'dotnet run' or running from VS I get in Edge only a warning, but since there is no "___cxx_global_var_init" warning in NET7 there might be some relation.

same for Firefox:

you need to install the wasm-tools workload in order to run emcc.
For NET7 you should see for "dotnet run -v n"

_CheckEmccIsExpectedVersion:
emcc --version
_WasmCompileNativeFiles:
embuilder.bat build MINIMAL
Compiling native assets with emcc with -O0. This may take a while ...
_WasmLinkDotNet:
Linking for initial memory $(EmccInitialHeapSize)=16777216 bytes. Set this msbuild property to change the valu
e.
Linking with emcc with -O0. This may take a while ...
emcc "@C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\7.0.12\runtimes\browser-w
asm\native\src\emcc-default.rsp" "@C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wa
sm\7.0.12\runtimes\browser-wasm\native\src\emcc-link.rsp" ....

NET 8.0 will compile with Emscripten.3.1.34.Sdk
and indeed a new warning will appear here: warning : undefined symbol: __cxx_global_var_init

This could be an LLVM bug.

(E. g. there is llvm/llvm-project#62243 and linked issues).

This could be an LLVM bug.

(E. g. there is llvm/llvm-project#62243 and linked issues).

The linker doesn’t crash in the dotnet build, only a warning is emitted. Might be because WasmAllowUndefinedSymbols is set to true.
WasmAllowUndefinedSymbols=true will link with ‘-s ERROR_ON_UNDEFINED_SYMBOLS=0’

I have found some other issues with same function name pointing to llvm, but I'm not sure why it's marked as wasm import and why emscripten doesn't provide implementation, or what the implementation should be.

Maybe it's the way how emscripten deals with undefined symbols.

Maybe it's the way how emscripten deals with undefined symbols.

Indeed; to be more precise, that is what -s ERROR_ON_UNDEFINED_SYMBOLS=0 causes the linker to do. There are a couple other settings as well (e. g. error on any undefined symbols, resolve them to unreachable stubs in wasm).

AFAIK __cxx_global_var_init is supposed to be the synthesized global constructor function (for one particular variable). See this godbolt for example.

I’m not a compiler guy and can’t comment on the WASM compiler/linker inners. Since it’s running well on NET7 I’m even not sure how things are connected.
I suggest two things:

Compile the NET7 project with Emscripten SDK from 8.
Bisect the 8.0 runtime to find where problem might come from.

When copying the onnxruntime.a from 7 to 8 even some possible onnx build differences will be ruled out.

that is what -s ERROR_ON_UNDEFINED_SYMBOLS=0 causes the linker to do

Needed, since I can’t change ONNX managed code, there are obviously other compliation conditions used than inside the wasm static library build.

@pavelsavara

@pavelsavara Any idea?

I didn't try to replicate, but high level I guess the same as SingleAccretion about ERROR_ON_UNDEFINED_SYMBOLS.
Try <WasmAllowUndefinedSymbols>true</WasmAllowUndefinedSymbols> in your project file.

I didn't try to replicate, but high level I guess the same as SingleAccretion about ERROR_ON_UNDEFINED_SYMBOLS. Try <WasmAllowUndefinedSymbols>true</WasmAllowUndefinedSymbols> in your project file.

That was defined all the time, see the sample repository. I'm just not convinced that it's not a problem inside the asset loader. I have no clue how to debug into the runtime further.

llvm/llvm-project#73095 might have fixed the __cxx_global_var_init undefined symbol issue.

@lewing

Now it needs to flow via emscripten to dotnet/rutntime. I guess we would not be doing emscripten upgrade on .Net 8 servicing release.

@lewing thoughts ?

FYI, emsdk's latest release has the fix too: https://github.com/emscripten-core/emsdk/releases/tag/3.1.50

found this issue via a search for my issue. I'm working on a Blazor WebAssembly app with a reference to a native file and since the .NET8 upgrade I get the following error during launch

"Error
    at Object.ke [as mono_exit] (http://localhost:31557/_framework/dotnet.js:3:19020)
    at Ll.e.onAbort.e.onAbort (http://localhost:31557/_framework/dotnet.runtime.8.0.1.rswtxkdyko.js:3:214204)
    at abort (http://localhost:31557/_framework/dotnet.native.8.0.1.gqt17pj1ci.js:859:22)
    at assert (http://localhost:31557/_framework/dotnet.native.8.0.1.gqt17pj1ci.js:390:5)
    at ___syscall_utimensat (http://localhost:31557/_framework/dotnet.native.8.0.1.gqt17pj1ci.js:5319:7)
    at utimensat (wasm://wasm/059a7ade:wasm-function[28003]:0x8a864f)
    at SystemNative_UTimensat (wasm://wasm/059a7ade:wasm-function[27555]:0x89747f)
    at do_icall (wasm://wasm/059a7ade:wasm-function[16162]:0x63dc0b)
    at do_icall_wrapper (wasm://wasm/059a7ade:wasm-function[16047]:0x638b28)
    at mono_interp_exec_method (wasm://wasm/059a7ade:wasm-function[16040]:0x62aa56)"

I'm not sure if this is the same one that is discussed here in the comments but so far I was not able to fix it. I have already tried adding <WasmAllowUndefinedSymbols>true</WasmAllowUndefinedSymbols>.

One thing that I noticed is that for me launching the app only fails in Debug mode - a Release build works fine.

Anybody some more ideas which could be helpful in my case?

UPDATE

i was able to fix it by adding <EmccCompileOptimizationFlag>-O1</EmccCompileOptimizationFlag> to the Debug configuration. I'm pretty sure that this problem I have is off-topic for this thread since ___syscall_utimensat is a different call than the one from the author - sorry for that

Navigation Menu

Repository navigation

NativeFileReference regression in .NET 8.0 #93538

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

4 remaining items

UPDATE

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

NativeFileReference regression in .NET 8.0 #93538

Description

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

Activity

maraf commented on Oct 16, 2023

b-straub commented on Oct 16, 2023

maraf commented on Oct 16, 2023

b-straub commented on Oct 16, 2023

4 remaining items

SingleAccretion commented on Oct 16, 2023

b-straub commented on Oct 16, 2023

maraf commented on Oct 16, 2023

SingleAccretion commented on Oct 16, 2023

b-straub commented on Oct 16, 2023

b-straub commented on Oct 16, 2023

b-straub commented on Oct 18, 2023

pavelsavara commented on Oct 19, 2023

b-straub commented on Oct 19, 2023

aheejin commented on Nov 30, 2023

pavelsavara commented on Nov 30, 2023

aheejin commented on Nov 30, 2023

nor0x commented on Jan 21, 2024

UPDATE

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions