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

fix: return proper nil on runtime.InstantiateModule errors (#2353) #2354

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

edman
Copy link

@edman edman commented Dec 25, 2024

Fixes #2353

Previously InstantiateModule could return a (*wasm.ModuleInstance)(nil) instead of a proper nil value.

So callers could get a nil dereference panic in code like:

m, _ := r.InstantiateModule(...)
if m != nil {       // this check passes
    defer m.Close() // but this causes a panic
}

@edman edman requested a review from mathetake as a code owner December 25, 2024 23:30
@@ -340,20 +339,20 @@ func (r *runtime) InstantiateModule(
if start == nil {
continue
}
if _, err = start.Call(ctx); err != nil {
if _, err := start.Call(ctx); err != nil {
_ = mod.Close(ctx) // Don't leak the module on error.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to the bug I found, but is this correct?

It looks like this shouldn't be closed in the success case below in L347.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if the module exited (even with exit code zero) it has already been closed. In that case, closing it again would not be an error.

…bs#2353)

Previously InstantiateModule could return a (*wasm.ModuleInstance)(nil)
instead of a proper nil value.

So callers could get a nil dereference panic in code like:

        m, _ := r.InstantiateModule(...)
        if m != nil {           // this check passes
                defer m.Close() // but this causes a panic
        }

Signed-off-by: Edman Anjos <[email protected]>
@ncruces
Copy link
Collaborator

ncruces commented Dec 26, 2024

This changes a lot more than the issue you had. If your issue was with line 318, why do you assume that returning the module and the error is not intentional when a start function "fails"?

I'll defer to @mathetake but I could see someone wanting to (e.g.) inspect the linear memory of a module that called exit(1) on a start function?

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.

runtime.InstantiateModule returns a "struct-wrapped" nil value
2 participants