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

Prevent module from closing when proc_exit is called with a 0 exit code #2367

Closed

Conversation

pkedy
Copy link
Contributor

@pkedy pkedy commented Jan 21, 2025

The latest stable release of TinyGo (0.35.0) invokes the WASI proc_exit syscall when the _start function is complete, even if the exit code is 0. Frameworks that use wazero likely expect an empty main() and call other exported functions. Because the module closes, this is broken in TinyGo 0.35.0. Any call thereafter also return sys.ExitError and basic host calls like fmt.Println are likely to panic.

This PR fixes the issue by returning out of procExitFn before closing the module if the exit code is 0.
Fixes #2357

The host program may still need to handle sys.ExitError being returned from _start. That does not change.

@pkedy pkedy requested a review from mathetake as a code owner January 21, 2025 03:58
@anuraaga
Copy link
Contributor

Hi @pkedy - AFAIK this isn't correct for CLIs which cannot be used after the module exits.

To use exported functions, the wasm needs to be built as c-shared. I updated the docs in https://github.com/tetratelabs/wazero/pull/2368/files#diff-fe83992f154cc181844b6bf965a0b6aba367c7b498a3a0db43b5b212d041531bR22

@pkedy
Copy link
Contributor Author

pkedy commented Jan 21, 2025

I'm looking into this from the perspective of a plugin library, which uses main() for set up some initial state for future calls.

I just tried -buildmode=c-shared and what I'm seeing is that state gets cleared out and my calls to other functions fails as a result. I'll keep digging into this.

@anuraaga
Copy link
Contributor

Ah also in case you missed it, the other change is to update WithStartFunctions("_initialize")

https://github.com/tetratelabs/wazero/pull/2368/files#diff-45c4202edd75629cf297edd9f2aa1d914fb21e0f4ac4235a673d185596dff610R45

I'm not sure if TinyGo would then expect initialization logic to be in init() or if main() would continue to work, but that would be an issue on TinyGo side if it's not supported.

I'm looking into this from the perspective of a plugin library,

Yeah before these were conflated with CLIs in the Go ecosystem, which didn't match the WASI spec, but now are distinct, with CLIs being the standard output and reactors (plugin libraries) being the c-shared buildmode output.

@pkedy
Copy link
Contributor Author

pkedy commented Jan 21, 2025

@anuraaga OK. Yep. Got it working. All makes sense now. While it 100% makes sense, it will take some time/effort for the TinyGo WASM community to transition to these changes. Thanks for educating me on this!

@pkedy pkedy closed this Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

examples: basic tinygo example fails with tinygo 0.35.0
2 participants