Stream: wit-bindgen

Topic: ✔ allocate_stack and cabi_realloc

view this post on Zulip Scott Waye (Sep 23 2023 at 00:44):

HI, I have a problem with initialising the dotnet runtime at the call to the first exported function. To initialize the runtime we call _initialize which ultimately tries to allocate the stack and calls into our implementation of cabi_realloc which is managed code, and needs the runtime initialized, and things fail. The stakc for this looks like

10: 0xdd6ebb - csharp_wasm_wit_many_arguments_Intrinsics__cabi_realloc
                    at C:\github\wit-bindgen-csharp\target\runtime-tests\many_arguments\csharp-many-arguments\ManyArguments.cs:44
   11: 0x13a37e0 - wit-component:adapter:wasi_snapshot_preview1!allocate_stack
   12: 0x139fd2f - wit-component:adapter:wasi_snapshot_preview1!fd_prestat_get
   13: 0x13a5569 - wit-component:shim!adapt-wasi_snapshot_preview1-fd_prestat_get
   14: 0xf7593f - <unknown>!__wasi_fd_prestat_get
   15: 0xf787e9 - <unknown>!__wasilibc_populate_preopens
   16: 0xc6ea - <unknown>!__wasm_call_ctors
   17: 0xc788 - <unknown>!_initialize
   18: 0x196c3 - InitializeRuntime()
                    at C:/github/runtimelab/artifacts/obj/coreclr/wasi.wasm.Debug/C:/github/runtimelab/src/coreclr/nativeaot/Bootstrap/main.cpp:197:9
   19: 0x1b379 - Thread::EnsureRuntimeInitialized()
                    at C:/github/runtimelab/artifacts/obj/coreclr/wasi.wasm.Debug/C:/github/runtimelab/src/coreclr/nativeaot/Runtime/thread.cpp:1220:13
   20: 0x1b172 - Thread::ReversePInvokeAttachOrTrapThread(ReversePInvokeFrame*)
                    at C:/github/runtimelab/artifacts/obj/coreclr/wasi.wasm.Debug/C:/github/runtimelab/src/coreclr/nativeaot/Runtime/thread.cpp:1182:13
   21: 0x1b5d5 - RhpReversePInvokeAttachOrTrapThread2
                    at C:/github/runtimelab/artifacts/obj/coreclr/wasi.wasm.Debug/C:/github/runtimelab/src/coreclr/nativeaot/Runtime/thread.cpp:1318:28
   22: 0x1b83d - RhpReversePInvoke
                    at C:/github/runtimelab/artifacts/obj/coreclr/wasi.wasm.Debug/C:/github/runtimelab/src/coreclr/nativeaot/Runtime/thread.cpp:1332:5
   23: 0xdd6b6b - csharp_wasm_wit_many_arguments_exports_ManyArgumentsWorld__wasmExportManyArguments
                    at C:\github\wit-bindgen-csharp\target\runtime-tests\many_arguments\csharp-many-arguments\ManyArguments.cs:34

Below frame 10 it goes ont to assert in the dotnet runtime. I saw https://github.com/bytecodealliance/wasm-tools/pull/919 which looks like it solves a related problem, but is there anything that I can configure to have allocate_stack not use cabi_realloc ? Seems that an adapter withouth allocation_state would work, but I guess I shouldn't be creating my own adapters?

wit-component: lazily allocate adapter stack when appropriate by dicej · Pull Request #919 · bytecodealliance/wasm-tools
Previously, I modified wit-component to use the main module cabi_realloc export to allocate the adapter stack when present. However, bytecodealliance/preview2-prototyping#78 pointed out that this c...

view this post on Zulip Alex Crichton (Sep 25 2023 at 14:44):

Componentization via wit-component has logic for using memory.grow to allocate a stack instead of calling cabi_realloc, but that's only conditionally used if the main module doesn't define cabi_realloc. For your use case though it seems like adding a flag to wasm-tools component new (or the equivalent thereof) to force stack-allocation-via-stack-growth may be the way to go?

view this post on Zulip Scott Waye (Sep 25 2023 at 19:17):

That sounds like it would work for me. If allocate_stack could be delayed until after __wasm_call_ctors that may also work, but may not be possible?

view this post on Zulip Scott Waye (Sep 25 2023 at 19:18):

I could of course move the cabi_realloc to umanaged (c/c++) code, but that would complicate the build and it would be nice to keep it all in managed code.

view this post on Zulip Alex Crichton (Sep 25 2023 at 19:21):

Moving it after is mostly a function of the ctors, if the ctors can avoid calling WASI functions then that'll work, but I think one of the ctors is invoking a WASI function which triggers allocation of the stack

view this post on Zulip Alex Crichton (Sep 25 2023 at 19:21):

in that I think it's already as lazy as can be

view this post on Zulip Alex Crichton (Sep 25 2023 at 19:21):

but I suspect that avoiding WASI functions may be pretty difficult

view this post on Zulip Scott Waye (Sep 25 2023 at 23:29):

I havn't created a PR in wasm-tools or wit-component to date. Would you see this option as being in the wit-component EncodingState ? Just so I can start on the right foot.

view this post on Zulip Alex Crichton (Sep 26 2023 at 00:10):

Seems reasonable to me yeah! There's a whole bunch of structs involved there.

view this post on Zulip Alex Crichton (Sep 26 2023 at 00:10):

I'd start at ComponentEncoder and work your way down to where that decision is made

view this post on Zulip Alex Crichton (Sep 26 2023 at 00:11):

although EncodingState I think can reach ComponentEncoder already

view this post on Zulip Scott Waye (Sep 28 2023 at 00:14):

Thanks, I'll close this thread as I think I have enough to go on.

view this post on Zulip Notification Bot (Sep 28 2023 at 00:15):

Scott Waye has marked this topic as resolved.

view this post on Zulip Scott Waye (Oct 04 2023 at 22:48):

I implemented this but I hit another problem, when executing the class ctors, there is this stack snippet

component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::State::new::h7ba8d3029d40ab1e
   12: 0x1b204a8 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::State::ptr::hca605544a6643e5c
   13: 0x1b20f28 - wit-component:adapter:wasi_snapshot_preview1!environ_sizes_get
   14: 0x1b2b597 - wit-component:shim!adapt-wasi_snapshot_preview1-environ_sizes_get

which also calls into cabi_realloc. I think I read somewhere there was some effort to remove the class ctors, but as things stand I see the solution for the c# runtime as providing an unmanaged implementation of cabi_realloceither in the AOT compiler or via an LLVM file (.ll)

view this post on Zulip Alex Crichton (Oct 04 2023 at 22:57):

hm so that should be fixable, the memory acquired there should be possible to acquire with memory.grow like the stack is. I suspect that the fix I suggested may not be complete. Would you be up to filing an issue about this? I can help poke at this tomorrow and see if the previous fix I suggested was wrong

view this post on Zulip Alex Crichton (Oct 04 2023 at 22:57):

if you've got a wasm I can play around with that would also be extra helpful for experimenting

view this post on Zulip Scott Waye (Oct 04 2023 at 23:45):

csharp-wasm.component.zip
This is the component that I'm using for the many-arguments runtime test

view this post on Zulip Scott Waye (Oct 04 2023 at 23:55):

https://github.com/bytecodealliance/wasm-tools/issues/1234

Wasm components: implementing cabi_reallock in managed dotnet code presents a problem · Issue #1234 · bytecodealliance/wasm-tools
Due to cabi_realloc being used from class constructors at initialization, there is a chicken and egg problem when initialising the dotnet runtime. If cabi_realloc is implemented in managed code, th...

view this post on Zulip Alex Crichton (Oct 05 2023 at 14:45):

@Scott Waye if I get this stack trace:

ManyArgumentsWorldImpl.ManyArguments
C:/github/runtimelab/src/native/libs/System.Native/pal_process_wasi.c (78): error 0: Not supported on WASI (false failed)
Assertion failed: false && "assert_msg failed" (C:/github/runtimelab/src/native/libs/System.Native/pal_process_wasi.c: SystemNative_SysLog: 78)
Error: failed to run main module `./csharp2.component.wasm`

Caused by:
    0: error while executing at wasm backtrace:
           0: 0x10b960a - <unknown>!abort
           1: 0x10ba848 - <unknown>!__assert_fail
           2: 0x10b132f - <unknown>!SystemNative_SysLog
           3: 0x8db9f0 - <unknown>!S_P_CoreLib_Interop_Sys___SysLog_g____PInvoke_128_0
           4: 0x70377b - <unknown>!S_P_CoreLib_Interop_Sys__SysLog
           5: 0xa6ca33 - <unknown>!S_P_CoreLib_System_Diagnostics_DebugProvider__WriteToDebugger
           6: 0x515506 - <unknown>!S_P_CoreLib_System_Diagnostics_DebugProvider__WriteCore
           7: 0xc17cca - <unknown>!S_P_CoreLib_System_Diagnostics_DebugProvider__Write
           8: 0xf757cf - <unknown>!__VirtualCall_S_P_CoreLib_System_Diagnostics_DebugProvider__Write
           9: 0x344efc - <unknown>!S_P_CoreLib_System_Diagnostics_DebugProvider__WriteLine
          10: 0xf757fd - <unknown>!__VirtualCall_S_P_CoreLib_System_Diagnostics_DebugProvider__WriteLine
          11: 0xdc0354 - <unknown>!S_P_CoreLib_System_Diagnostics_DebugProvider__WriteAssert
          12: 0x12f74b - <unknown>!S_P_CoreLib_System_Diagnostics_DebugProvider__Fail
          13: 0xf757a1 - <unknown>!__VirtualCall_S_P_CoreLib_System_Diagnostics_DebugProvider__Fail
          14: 0xa5c7f6 - <unknown>!S_P_CoreLib_System_Diagnostics_Debug__Fail_0
          15: 0x33c2d6 - <unknown>!S_P_CoreLib_System_Diagnostics_Debug__Assert_2
          16: 0xa4d6b5 - <unknown>!S_P_CoreLib_System_Diagnostics_Debug__Assert
          17: 0x1202fd - <unknown>!csharp_wasm_ManyArgumentsWorldImpl__ManyArguments
          18: 0xdb58ee - <unknown>!csharp_wasm_wit_many_arguments_exports_ManyArgumentsWorld__wasmExportManyArguments
       note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
    1: wasm trap: wasm `unreachable` instruction executed

does that look like progress?

view this post on Zulip Alex Crichton (Oct 05 2023 at 14:46):

That was via a component that was generated with this patch to wasm-tools:

diff --git a/crates/wit-component/src/gc.rs b/crates/wit-component/src/gc.rs
index c4e1dff6..f433b09f 100644
--- a/crates/wit-component/src/gc.rs
+++ b/crates/wit-component/src/gc.rs
@@ -52,7 +52,7 @@ pub fn run<T>(
     }
     assert!(!module.exports.is_empty());
     module.liveness()?;
-    module.encode(main_module_realloc)
+    module.encode(None)
 }

 fn always_keep(name: &str) -> bool {

view this post on Zulip Alex Crichton (Oct 05 2023 at 14:47):

before that I was getting the same stack trace you mentioned in the issue from last night

view this post on Zulip Scott Waye (Oct 05 2023 at 14:52):

Yes, that looks like it fails on an assert in the actual test which means it has passed the intialization :-)

view this post on Zulip Scott Waye (Oct 05 2023 at 14:53):

But i can try that patch locally, where it should pass the test. Give me a couple of hours and I'll update here.

view this post on Zulip Alex Crichton (Oct 05 2023 at 14:54):

ok cool, in that case I think using main_module_realloc vs "always pass None" there would be a good flag to add to wasm-tools component new

Last updated: Oct 23 2024 at 20:03 UTC