[wasm] Tests on CI: Full version of libmono-component-diagnostics_tracing-static.a is linked instead of stub #61294

pavelsavara · 2021-11-07T14:33:36Z

Description

I'm improving wasm app startup in PR.
I'm in-tree linking with <WasmBuildNative>true</WasmBuildNative>

libmono-component-diagnostics_tracing-static.a
is included in link files via

<_WasmNativeFileForLinking Include="$(MicrosoftNetCoreAppRuntimePackRidNativeDir)*.a" Exclude="@(_MonoRuntimeComponentDontLink->'$(MicrosoftNetCoreAppRuntimePackRidNativeDir)%(Identity)')" />

because _MonoRuntimeComponentDontLink is empty and libmono-component-diagnostics_tracing-static.a on the path.

 ==== JS stack trace =========================================

  Security context: 0x015408210491 <JSObject>#0#
      0: builtin exit frame: trace(this=0x015408205ac9 <console map = 0000015408242911>#1#,0x015408205ac9 <console map = 0000015408242911>#1#,0x0154084d2ec9 <String[25]: c"ep_rt_mono_component_init">)

      1: mono_wasm_trace_logger [00000154083CEE79] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:722] [bytecode=00000154083A9AF5 offset=135](this=0x0154083c6259 <Object map = 0000015408249121>#2#,0,34436,9256920,4,0)
      2: _mono_wasm_trace_logger(aka _mono_wasm_trace_logger) [00000154083C31B9] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:10669] [bytecode=0000015408388C25 offset=27](this=0x0154080423b5 <undefined>)
      3: WasmToJsFrame [pc: 0000018BB10064F4]
      4: WASM [wasm://wasm/02b2b5ba], function #17611 ('wasm_trace_logger'), pc=0000018BB1086DBA (+0x3a), pos=3095058 (+11)
      5: WASM [wasm://wasm/02b2b5ba], function #5726 ('eglib_log_adapter'), pc=0000018BB0C22ED7 (+0x157), pos=1432682 (+100)
      6: WASM [wasm://wasm/02b2b5ba], function #16824 ('monoeg_g_logstr'), pc=0000018BB072A90C (+0x12c), pos=2972753 (+83)
      7: WASM [wasm://wasm/02b2b5ba], function #16822 ('monoeg_g_logv_nofree'), pc=0000018BB072ABAF (+0x14f), pos=2972580 (+127)
      8: WASM [wasm://wasm/02b2b5ba], function #16826 ('monoeg_assertion_message'), pc=0000018BB072A630 (+0x70), pos=2972882 (+44)
      9: WASM [wasm://wasm/02b2b5ba], function #1770 ('mono_component_event_pipe_init'), pc=0000018BB0E7E50E (+0x2e), pos=696511 (+7)
     10: WASM [wasm://wasm/02b2b5ba], function #2859 ('mono_components_init'), pc=0000018BB0D8783D (+0xdd), pos=835888 (+52)
     11: WASM [wasm://wasm/02b2b5ba], function #15658 ('mini_init'), pc=0000018BB0A3C469 (+0xa9), pos=2687714 (+66)
     12: WASM [wasm://wasm/02b2b5ba], function #15864 ('mono_jit_init_version'), pc=0000018BB0958E4C (+0x6c), pos=2728793 (+40)
     13: WASM [wasm://wasm/02b2b5ba], function #17605 ('mono_wasm_load_runtime'), pc=0000018BB108E2C3 (+0x2a3), pos=3094573 (+354)
     14: JsToWasmFrame [pc: 00000154000ED917]
     15: /* anonymous */(aka /* anonymous */) [0000015408385981] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:11364] [bytecode=00000154083A83F1 offset=36](this=0x015408042235 <null>)
     16: ccall(aka ccall) [00000154083D2D69] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:4903] [bytecode=000001540839FB19 offset=134](this=0x0154080423b5 <undefined>,0x0154082135d5 <String[22]: #mono_wasm_load_runtime>,0x015408042235 <null>,0x0154083d4911 <JSArray[2]>#3#,0x0154084d1ea5 <Arguments map = 0000015408244699>#4#,0x0154080423b5 <undefined>)
     17: /* anonymous */(aka /* anonymous */) [00000154084D1E75] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:4923] [bytecode=000001540839F8D5 offset=22](this=0x0154080423b5 <undefined>)
     18: /* anonymous */ [000001540823A33D] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:124] [bytecode=000001540839F595 offset=100](this=0x0154083ceab1 <Object map = 0000015408245481>#5#)
     19: finalize_startup(aka finalize_startup) [00000154083D015D] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:3025] [bytecode=00000154083A78C5 offset=92](this=0x0154080423b5 <undefined>,0x0154083cea79 <Object map = 0000015408252E01>#6#)
     20: mono_wasm_on_runtime_initialized(aka mono_wasm_on_runtime_initialized) [00000154083D00C1] [C:/Dev/runtime/src/mono/sample/wasm/console-v8/bin/Debug/AppBundle/dotnet.js:2926] [bytecode=0000015408390AC1 offset=118](this=0x0154080423b5 <undefined>)
     21: /* anonymous */ [00000154087072C5](this=0x015408203201 <JSGlobal Object>#7#,0x0154080423b5 <undefined>)
     22: StubFrame [pc: 000001540013F578]
     23: StubFrame [pc: 00000154000AA3FE]
     24: EntryFrame [pc: 00000154000878B7]
  =====================

Reproduction Steps

In the PR I'm building sample project with
<WasmBuildNative>true</WasmBuildNative> in-tree.

Expected behavior

No assert

Actual behavior

Assert and failure

Regression?

Don't know

Known Workarounds

No response

Configuration

Debug

Other information

No response

The text was updated successfully, but these errors were encountered:

ghost · 2021-11-07T14:33:39Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

I'm improving wasm app startup in some PR and I now catch exceptions in mono_wasm_load_runtime.
I saw this assert, but I have not investigated yet.

dotnet.js:5823 * Assertion at C:/Dev/runtime/src/native/eventpipe/ds-ipc-pal-socket.c:738, condition `!"Failed to set permissions on diagnostics IPC socket."' not met

653621 @ dotnet.js:5823
_emscripten_asm_const_int @ dotnet.js:10120
$wasm_trace_logger @ dotnet.wasm:0x30d900
$eglib_log_adapter @ dotnet.wasm:0x176a7b
$monoeg_g_logstr @ dotnet.wasm:0x2ef719
$monoeg_g_logv_nofree @ dotnet.wasm:0x2ef66c
$monoeg_assertion_message @ dotnet.wasm:0x2ef79a
$mono_assertion_message @ dotnet.wasm:0x2ef7f9
$ipc_init_listener @ dotnet.wasm:0xda17d
$ds_ipc_alloc @ dotnet.wasm:0xda016
$ipc_stream_factory_build_and_add_port @ dotnet.wasm:0xdcef1
$ds_ipc_stream_factory_configure @ dotnet.wasm:0xdc2b9
$ds_server_init @ dotnet.wasm:0xdbdbc
$mono_runtime_init_checked @ dotnet.wasm:0x623d7
$mini_init @ dotnet.wasm:0x2a999a
$mono_jit_init_version @ dotnet.wasm:0x2b39b1
$mono_wasm_load_runtime @ dotnet.wasm:0x30d6d8
Module._mono_wasm_load_runtime @ dotnet.js:11442
ccall @ dotnet.js:5012
(anonymous) @ dotnet.js:5032
wf.<computed> @ dotnet.js:140
_finalize_startup @ dotnet.js:3288
onPendingRequestComplete @ dotnet.js:3386
processFetchResponseBuffer @ dotnet.js:3404
(anonymous) @ dotnet.js:3423
Promise.then (async)
handleFetchResponse @ dotnet.js:3423
Promise.then (async)
attemptNextSource @ dotnet.js:3476
(anonymous) @ dotnet.js:3483
_load_assets_and_runtime @ dotnet.js:3407
mono_load_runtime_and_bcl_args @ dotnet.js:3189
onRuntimeInitialized @ main.js:34
moduleExt.onRuntimeInitialized @ dotnet.js:4288
doRun @ dotnet.js:12068
run @ dotnet.js:12083
runCaller @ dotnet.js:12038
removeRunDependency @ dotnet.js:5613
receiveInstance @ dotnet.js:5748
receiveInstantiationResult @ dotnet.js:5759
Promise.then (async)
(anonymous) @ dotnet.js:5782
Promise.then (async)
instantiateAsync @ dotnet.js:5780
createWasm @ dotnet.js:5808
createRuntime @ dotnet.js:11399
(anonymous) @ dotnet.js:12134
dotnet.js:5823

Reproduction Steps

Use src\mono\sample\wasm\browser sample but catch exceptions in _finalize_startup

Expected behavior

No assert

Actual behavior

Assert and silent failure

Regression?

Don't know

Known Workarounds

No response

Configuration

Debug

Other information

No response

Author:	pavelsavara
Assignees:	-
Labels:	`arch-wasm`
Milestone:	-

ghost · 2021-11-07T14:33:42Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

I'm improving wasm app startup in some PR and I now catch exceptions in mono_wasm_load_runtime.
I saw this assert, but I have not investigated yet.

dotnet.js:5823 * Assertion at C:/Dev/runtime/src/native/eventpipe/ds-ipc-pal-socket.c:738, condition `!"Failed to set permissions on diagnostics IPC socket."' not met

653621 @ dotnet.js:5823
_emscripten_asm_const_int @ dotnet.js:10120
$wasm_trace_logger @ dotnet.wasm:0x30d900
$eglib_log_adapter @ dotnet.wasm:0x176a7b
$monoeg_g_logstr @ dotnet.wasm:0x2ef719
$monoeg_g_logv_nofree @ dotnet.wasm:0x2ef66c
$monoeg_assertion_message @ dotnet.wasm:0x2ef79a
$mono_assertion_message @ dotnet.wasm:0x2ef7f9
$ipc_init_listener @ dotnet.wasm:0xda17d
$ds_ipc_alloc @ dotnet.wasm:0xda016
$ipc_stream_factory_build_and_add_port @ dotnet.wasm:0xdcef1
$ds_ipc_stream_factory_configure @ dotnet.wasm:0xdc2b9
$ds_server_init @ dotnet.wasm:0xdbdbc
$mono_runtime_init_checked @ dotnet.wasm:0x623d7
$mini_init @ dotnet.wasm:0x2a999a
$mono_jit_init_version @ dotnet.wasm:0x2b39b1
$mono_wasm_load_runtime @ dotnet.wasm:0x30d6d8
Module._mono_wasm_load_runtime @ dotnet.js:11442
ccall @ dotnet.js:5012
(anonymous) @ dotnet.js:5032
wf.<computed> @ dotnet.js:140
_finalize_startup @ dotnet.js:3288
onPendingRequestComplete @ dotnet.js:3386
processFetchResponseBuffer @ dotnet.js:3404
(anonymous) @ dotnet.js:3423
Promise.then (async)
handleFetchResponse @ dotnet.js:3423
Promise.then (async)
attemptNextSource @ dotnet.js:3476
(anonymous) @ dotnet.js:3483
_load_assets_and_runtime @ dotnet.js:3407
mono_load_runtime_and_bcl_args @ dotnet.js:3189
onRuntimeInitialized @ main.js:34
moduleExt.onRuntimeInitialized @ dotnet.js:4288
doRun @ dotnet.js:12068
run @ dotnet.js:12083
runCaller @ dotnet.js:12038
removeRunDependency @ dotnet.js:5613
receiveInstance @ dotnet.js:5748
receiveInstantiationResult @ dotnet.js:5759
Promise.then (async)
(anonymous) @ dotnet.js:5782
Promise.then (async)
instantiateAsync @ dotnet.js:5780
createWasm @ dotnet.js:5808
createRuntime @ dotnet.js:11399
(anonymous) @ dotnet.js:12134
dotnet.js:5823

Reproduction Steps

Use src\mono\sample\wasm\browser sample but catch exceptions in _finalize_startup

Expected behavior

No assert

Actual behavior

Assert and silent failure

Regression?

Don't know

Known Workarounds

No response

Configuration

Debug

Other information

No response

Author:	pavelsavara
Assignees:	-
Labels:	`arch-wasm`, `area-System.Net.Sockets`, `untriaged`
Milestone:	-

pavelsavara · 2021-11-07T14:36:14Z

@lambdageek thoughts ? Should eventpipe try to start in wasm ?

ghost · 2021-11-07T18:11:38Z

Tagging subscribers to this area:
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

I'm improving wasm app startup in some PR and I now catch exceptions in mono_wasm_load_runtime.
I saw this assert, but I have not investigated yet.
There is chance that my local changes are causing it.

dotnet.js:5823 * Assertion at C:/Dev/runtime/src/native/eventpipe/ds-ipc-pal-socket.c:738, condition 
!"Failed to set permissions on diagnostics IPC socket."' not met

653621 @ dotnet.js:5823
_emscripten_asm_const_int @ dotnet.js:10120
$wasm_trace_logger @ dotnet.wasm:0x30d900
$eglib_log_adapter @ dotnet.wasm:0x176a7b
$monoeg_g_logstr @ dotnet.wasm:0x2ef719
$monoeg_g_logv_nofree @ dotnet.wasm:0x2ef66c
$monoeg_assertion_message @ dotnet.wasm:0x2ef79a
$mono_assertion_message @ dotnet.wasm:0x2ef7f9
$ipc_init_listener @ dotnet.wasm:0xda17d
$ds_ipc_alloc @ dotnet.wasm:0xda016
$ipc_stream_factory_build_and_add_port @ dotnet.wasm:0xdcef1
$ds_ipc_stream_factory_configure @ dotnet.wasm:0xdc2b9
$ds_server_init @ dotnet.wasm:0xdbdbc
$mono_runtime_init_checked @ dotnet.wasm:0x623d7
$mini_init @ dotnet.wasm:0x2a999a
$mono_jit_init_version @ dotnet.wasm:0x2b39b1
$mono_wasm_load_runtime @ dotnet.wasm:0x30d6d8
Module._mono_wasm_load_runtime @ dotnet.js:11442
ccall @ dotnet.js:5012
(anonymous) @ dotnet.js:5032
wf.<computed> @ dotnet.js:140
_finalize_startup @ dotnet.js:3288
onPendingRequestComplete @ dotnet.js:3386
processFetchResponseBuffer @ dotnet.js:3404
(anonymous) @ dotnet.js:3423
Promise.then (async)
handleFetchResponse @ dotnet.js:3423
Promise.then (async)
attemptNextSource @ dotnet.js:3476
(anonymous) @ dotnet.js:3483
_load_assets_and_runtime @ dotnet.js:3407
mono_load_runtime_and_bcl_args @ dotnet.js:3189
onRuntimeInitialized @ main.js:34
moduleExt.onRuntimeInitialized @ dotnet.js:4288
doRun @ dotnet.js:12068
run @ dotnet.js:12083
runCaller @ dotnet.js:12038
removeRunDependency @ dotnet.js:5613
receiveInstance @ dotnet.js:5748
receiveInstantiationResult @ dotnet.js:5759
Promise.then (async)
(anonymous) @ dotnet.js:5782
Promise.then (async)
instantiateAsync @ dotnet.js:5780
createWasm @ dotnet.js:5808
createRuntime @ dotnet.js:11399
(anonymous) @ dotnet.js:12134
dotnet.js:5823

Reproduction Steps

Use src\mono\sample\wasm\browser sample but catch exceptions in _finalize_startup

Expected behavior

No assert

Actual behavior

Assert and silent failure

Regression?

Don't know

Known Workarounds

No response

Configuration

Debug

Other information

No response

Author:	pavelsavara
Assignees:	-
Labels:	`arch-wasm`, `area-VM-meta-mono`
Milestone:	-

pavelsavara · 2021-11-08T16:04:37Z

It seems that in-tree native build doesn't set WasmNativeWorkload and therefore _WasmSelectRuntimeComponentsForLinking is not running and _MonoRuntimeComponentDontLink is empty. That would include libmono-component-diagnostics_tracing-static.a in list of files to link before libmono-component-diagnostics_tracing-stub-static.a.

pavelsavara · 2021-11-08T17:03:26Z

Also note that we produce artifacts\bin\microsoft.netcore.app.runtime.browser-wasm\Debug\runtimes\browser-wasm\native\libmono-component-diagnostics_tracing-static.a which doesn't need to be there for wasm.

pavelsavara · 2021-11-08T17:08:09Z

@radical could you please advise or help fixing it ?

radekdoulik · 2021-11-08T17:19:50Z

I think we should set our defaults to select right components in case WasmNativeWorkload is not true here:

runtime/src/mono/wasm/build/WasmApp.Native.targets

Line 268 in 5a078b5

    
           <Target Name="_WasmSelectRuntimeComponentsForLinking" Condition="'$(WasmNativeWorkload)' == true" DependsOnTargets="_MonoSelectRuntimeComponents" />

The default selection should be

    libmono-component-hot_reload-static.a
    libmono-component-debugger-static.a
    libmono-component-diagnostics_tracing-stub-static.a

pavelsavara · 2021-11-08T20:30:22Z

Attempt to fix it here https://github.com/dotnet/runtime/pull/61313/files#diff-9aef04edc740c7aadf146f6890e8316ec4e65030186727ea6286411efea20d02R278

radical · 2021-11-25T03:47:10Z

note to self: Doing this properly is a bit tricky. There are two parts to this:

enable mono targets sdk to be used correctly with in-tree test runs
also, we want to use workloads to run tests on helix, for non-aot/eat runs also.

And I want to ensure that it is still easy to run tests, and debug locally. All of that multiplies the number of cases here. I have most of it solved in #61863 . But it's WIP.

pavelsavara · 2021-12-02T19:02:00Z

I updated the stack trace in description.
I just added some logs and now I'm sure it's executing ep_rt_mono_component_init

radical · 2022-08-09T21:53:41Z

IIUC, this is specifically for running tests on helix. As mentioned in #61294 (comment) , this is non-trivial, and won't get done for 7.0.0 . Though please mention if this is blocking some testing scenarios.

pavelsavara added the arch-wasm WebAssembly architecture label Nov 7, 2021

dotnet-issue-labeler bot added area-System.Net.Sockets untriaged New issue has not been triaged by the area owner labels Nov 7, 2021

pavelsavara removed untriaged New issue has not been triaged by the area owner area-System.Net.Sockets labels Nov 7, 2021

jeffschwMSFT added the area-VM-meta-mono label Nov 7, 2021

pavelsavara changed the title ~~[wasm] Assertion ds-ipc-pal-socket.c:738: Failed to set permissions on diagnostics IPC socket.~~ [wasm] Full version of libmono-component-diagnostics_tracing-static.a is linked when we in-tree link with WasmBuildNative, instead of stub Nov 8, 2021

pavelsavara changed the title ~~[wasm] Full version of libmono-component-diagnostics_tracing-static.a is linked when we in-tree link with WasmBuildNative, instead of stub~~ [wasm] Full version of libmono-component-diagnostics_tracing-static.a is linked instead of stub Nov 8, 2021

pavelsavara mentioned this issue Nov 9, 2021

[Wasm] JS modularization #61313

Merged

ghost added the in-pr There is an active PR which will close this issue when it is merged label Nov 9, 2021

pavelsavara assigned radical Nov 24, 2021

ghost removed the in-pr There is an active PR which will close this issue when it is merged label Nov 24, 2021

pavelsavara mentioned this issue Nov 29, 2021

[WASM] System.Text.Json.Serialization.Tests - Specified cast is not valid. #62125

Open

pavelsavara mentioned this issue Dec 6, 2021

[wasm] updated samples for ES6 and CJS #62292

Merged

ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Dec 6, 2021

lambdageek added this to the 7.0.0 milestone Jul 5, 2022

radical changed the title ~~[wasm] Full version of libmono-component-diagnostics_tracing-static.a is linked instead of stub~~ [wasm] Tests on CI: Full version of libmono-component-diagnostics_tracing-static.a is linked instead of stub Aug 9, 2022

radical modified the milestones: 7.0.0, 8.0.0 Aug 9, 2022

lambdageek added area-Build-mono and removed area-VM-meta-mono labels Jul 12, 2023

lewing modified the milestones: 8.0.0, 9.0.0 Jul 24, 2023

ilonatommy unassigned radical May 31, 2024

maraf self-assigned this May 31, 2024

pavelsavara assigned pavelsavara and unassigned maraf Jul 4, 2024

pavelsavara modified the milestones: 9.0.0, Future Jul 9, 2024

[wasm] Tests on CI: Full version of libmono-component-diagnostics_tracing-static.a is linked instead of stub #61294

[wasm] Tests on CI: Full version of libmono-component-diagnostics_tracing-static.a is linked instead of stub #61294

Comments

pavelsavara commented Nov 7, 2021 • edited Loading

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

ghost commented Nov 7, 2021

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

ghost commented Nov 7, 2021

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

pavelsavara commented Nov 7, 2021

ghost commented Nov 7, 2021

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

pavelsavara commented Nov 8, 2021 • edited Loading

pavelsavara commented Nov 8, 2021

pavelsavara commented Nov 8, 2021

radekdoulik commented Nov 8, 2021

pavelsavara commented Nov 8, 2021

radical commented Nov 25, 2021

pavelsavara commented Dec 2, 2021

radical commented Aug 9, 2022

pavelsavara commented Nov 7, 2021 •

edited

Loading

pavelsavara commented Nov 8, 2021 •

edited

Loading