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

ockam_vault_extern_error_t's definition/lack of documentation might encourage memory leaks. #1562

Closed
thomcc opened this issue Jul 19, 2021 · 2 comments
Assignees

Comments

@thomcc
Copy link
Contributor

thomcc commented Jul 19, 2021

When filing #1561, I noticed an issue which is plausibly a bit more serious. Specifically, ockam_vault_extern_error_t::domain is allocated by CString::into_raw (which notes that it's C's responsibility to free https://github.com/ockam-network/ockam/blob/develop/implementations/rust/ockam/ockam_ffi/src/error.rs#L37), but no API to free resources managed by the ockam_vault_extern_error_t is provided, nor is the fact that it's needed documented.

Moreover, this field being a const char* parameter implies that it'd be invalid for the caller to free it. If I saw this in a C api, I'd probably expect that it's a pointer to a static error description string.

That said, fixing this is kind of a pain, and maybe it doesn't matter in practice, since errors should be rare — I'm only careful about noticing it since my background includes a lot of FFI work, including a very similar type.

@SanjoDeundiak
Copy link
Member

Thanks @thomcc for submitting this issue. We used to have static strings for error domains, but it was impossible to use with our Actor model. More details here #967
Creating API for freeing memory is something that needs to be done and integrated into our ffi layer. If you're up to doing that, it would be great!

@etorreborre
Copy link
Member

This was fixed with this PR: #2138

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants