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: Do not close wazero module on error (#3758) #3759

Merged
merged 1 commit into from
Dec 27, 2024

Conversation

edman
Copy link
Contributor

@edman edman commented Dec 22, 2024

Fixes #3758

wazero takes care not to leak modules when InstantiateModule returns an error.

This means that sqlc will call result.Close a second time if a non nil module was returned, which causes a segfault.

Edit: this statement is wrong. See my comment below for the correct explanation of the segfault.

@dosubot dosubot bot added size:XS This PR changes 0-9 lines, ignoring generated files. 🔧 golang labels Dec 22, 2024
@kyleconroy
Copy link
Collaborator

wazero takes care not to leak modules when InstantiateModule returns an error.

So does wazero return a valid module and an error message in these cases? checkError also looks at stderr, which make be written to if InstantiateModule does not return an error. Merged as is we wouldn't call result.Close in all cases.

wazero takes care not to leak modules when `InstantiateModule` returns
an error.

This means that sqlc will call `result.Close` a second time if a non nil
module was returned, which causes a segfault.
@edman
Copy link
Contributor Author

edman commented Dec 25, 2024

So does wazero return a valid module and an error message in these cases?

Ok so.. Your comment made me go back and track more closely what happened. And I found sqlc actually tripped this https://go.dev/doc/faq#nil_error interesting behavior of go with nil values and interfaces.

See this example https://go.dev/play/p/66QShXidalq

Basically we can't always compare result != nil, where result is an interface type. That might work or not depending on wazero's code. (it gets awkward when you remember that error is an interface).

checkError also looks at stderr, which make be written to if InstantiateModule does not return an error. Merged as is we wouldn't call result.Close in all cases.

checkError doesn't look at stderr when err is nil to begin with, so it should close in all relevant cases? But I agree the indirection makes things less clear.

I'm thinking we can just defer close when err == nil? Please see the new commit.

@kyleconroy kyleconroy merged commit cfe6c55 into sqlc-dev:main Dec 27, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:XS This PR changes 0-9 lines, ignoring generated files. 🔧 golang
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WASM plugin error causes SIGSEGV
2 participants