Can't print DateTimeOffset from exported function unless called from Main before

[RReverser]

Ok I spent pretty much entire day today trying to figure out what's going on here because this bug reproduces in pretty weird ways, but now I'm giving up and going to need some help please. @SteveSandersonMS.

Here's reasonably minimal sample that at least prints a useful error message: https://gist.github.com/RReverser/db10fc4dfe039630eb24821e1d619bf7 (in other instances I ran into, it just crashes)

Error:

C:\Users\me\Documents\MyFirstWasiApp> dotnet build && node tester.mjs         
MSBuild version 17.5.1+f6fdcf537 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  MyFirstWasiApp -> C:\Users\me\Documents\MyFirstWasiApp\bin\Debug\net7.0\MyFirstWasiApp.dll
  MyFirstWasiApp -> C:\Users\me\Documents\MyFirstWasiApp\bin\Debug\net7.0\MyFirstWasiApp.wasm

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.51
(node:9388) ExperimentalWarning: WASI is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
started
[wasm_trace_logger] Process terminated.
[wasm_trace_logger] Encountered infinite recursion while looking up resource 'Arg_DllNotFoundException' in System.Private.CoreLib. Verify the installation of .NET is complete and does not need repairing, and that the state of the process has not become corrupted.
wasm://wasm/021e6e66:1

RuntimeError: unreachable
    at wasm://wasm/021e6e66:wasm-function[7608]:0x40426c
    at wasm://wasm/021e6e66:wasm-function[1804]:0x17e17a
    at wasm://wasm/021e6e66:wasm-function[1871]:0x184647
    at wasm://wasm/021e6e66:wasm-function[448]:0xbf9dc
    at wasm://wasm/021e6e66:wasm-function[395]:0xbbf59
    at wasm://wasm/021e6e66:wasm-function[323]:0x65c17
    at wasm://wasm/021e6e66:wasm-function[322]:0x61cdb
    at wasm://wasm/021e6e66:wasm-function[6283]:0x365c2f
    at wasm://wasm/021e6e66:wasm-function[3064]:0x20f893
    at wasm://wasm/021e6e66:wasm-function[3062]:0x20f661

Node.js v20.0.0

What's weird is, if I uncomment printing DateTimeOffset.UnixEpoch (I chose it just because it's a constant, to reduce repro and not depend on WASI time) in Main, then both that one and the one in HelloWorld work fine, but if it's commented out (or, as in my original project, doesn't exit), then logging instances of DateTimeOffset crashes everywhere else as well.

Judging by this message and the observed behaviour, I suspect there is some lazy initialisation happening that only loads DLLs if they are needed by Main function but not other exports? Not sure what to make of it or how to fix it.

[SteveSandersonMS]

I haven't archived this repo yet or updated the README, but from here on all the development work and focus is on the WASI workload in the real .NET SDK, from .NET 8 Preview 4 onwards. There's a video about it at https://twitter.com/stevensanderson/status/1658845798212202496 and a blog post with early docs coming soon.

So, if you could try this out with the new runtime that would be great. If it still seems to have a bug, please consider filing an issue on https://github.com/dotnet/runtime

[RReverser]

I'm definitely keeping an eye on .NET Preview 8 and tried it, but it's too early to replace this repo for non-WASI tasks, particularly due to missing custom import/export functionality which you showed me how to use in the other issue couple months ago.

I'll be happy to switch over when that's implemented but for now we're stuck with Wasi.Sdk and would love some help with this bug.

[SteveSandersonMS]

I think it's still possible to do the same import/export techniques with new runtime implementation. The import/export facilities that are still to be implemented are new, better ones. I'm afraid I won't have capacity to investigate issues on this repo any time soon - sorry!

[RReverser]

I think when I tried I was running into this issue (at least I think it's the same one) you mentioned here:

https://github.com/dotnet/runtime/issues/65895#issuecomment-1546766222

It ignores pinvokes unless they correspond to an entry on _WasmNativeFileForLinking (even though when you want to generate an import, you won't be linking with any module for it)

But maybe it was for the new binding system and not old one? I'll give it another try but if it still doesn't work, I guess I'm stuck.

Do you have a working example with custom C bindings that works with .Net Preview 8 that you could point me to?

[RReverser]

Right, just double-checked and the problem with .NET 8 is that no matter what I do, I can't get my own imports/exports to show up in generated Wasm.

[RReverser]

And also WasiAfterRuntimeLoaded doesn't work:

/home/rreverser/.dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/8.0.0-preview.5.23280.8/Sdk/WasiApp.Native.targets(465,26): error MSB4012: The expression "-D WASI_AFTER_RUNTIME_LOADED_DECLARATIONS="@(WasiAfterRuntimeLoadedDeclarations, ' ')"" cannot be used in this context. Item lists cannot be concatenated with other strings where an item list is expected. Use a semicolon to separate multiple item lists. [/home/rreverser/spacetime-web/api/module_templates/cs/StdbModule.csproj]

And then there are missing symbols for all those utils like mono_wasm_invoke_method.

It just seems a lot less mature than Wasi.Sdk for now which at least does work today.

[rs22]

@RReverser were you eventually successful with .NET 8, now that it's released? I asked this question on SO before (https://stackoverflow.com/q/77848793/5831785), but it seems nobody was able to do it yet.

[RReverser]

@rs22 Yes, we are using it successfully now. I'm going to write a blog post soon-ish.