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 various issues in ockam_ffi. #2131

Closed
wants to merge 3 commits into from
Closed

Fix various issues in ockam_ffi. #2131

wants to merge 3 commits into from

Conversation

thomcc
Copy link
Contributor

@thomcc thomcc commented Oct 30, 2021

I had some computer issues this morning that I fixed by updating the OS, which meant that I wasn't on my primary dev machine for the day (I forgot to switch back after the update completed).

As a result of this, I decided to do my audit of the FFI code, which I had been meaning to do for a while (since at Mozilla, this kind of FFI code was my responsibility, so I know some non-obvious pitfalls to watch out for, and the solutions to them).

Fixes #1562, as well as the fact that we unwind from extern "C" fns, which is UB (fixing this robustly is a bit tricky, but not too bad — doing this correctly is a bit involved, but the implementation here should be robust.

I also cleaned up a use of #[cfg(feature = "bls")] when there's no bls feature, which is not that important, but caused a false positive error in my editor.

@thomcc thomcc requested a review from SanjoDeundiak October 30, 2021 01:03
@thomcc thomcc requested a review from mrinalwadhwa as a code owner October 30, 2021 01:03
@thomcc thomcc temporarily deployed to contributors October 30, 2021 01:03 Inactive
where
F: FnOnce() -> Result<(), FfiOckamError>,
{
let result = std::panic::catch_unwind(std::panic::AssertUnwindSafe(f));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

AssertUnwindSafe here doesn't really matter — UnwindSafe is dubious at best, is unrelated to safety, and we aren't in a position to properly represent it anyway (as propagating the unwinding would be UB).

struct AbortOnDrop;
impl Drop for AbortOnDrop {
fn drop(&mut self) {
eprintln!("Panic from error drop, aborting!");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

In principal, this eprintln! could panic (if stderr is closed, for example), but this Drop can only be called in response to a panic, and Rust calls core::intrinsics::abort if it runs a Drop that panics while it's already panicking.

That is to say, we could implement this Drop as panic!("Panic from error drop, aborting!"), but this has notably better user experience, as core::intrinsics::abort is a SIGILL (on x86), not a SIGABRT.

@thomcc thomcc force-pushed the thomcc/ffi-cleanup branch from c623001 to cd332f9 Compare October 30, 2021 01:12
@jdspdx jdspdx mentioned this pull request Nov 1, 2021
@jdspdx
Copy link
Contributor

jdspdx commented Nov 1, 2021

Merged as #2138 - thanks!

@jdspdx jdspdx closed this Nov 1, 2021
@thomcc thomcc deleted the thomcc/ffi-cleanup branch November 20, 2021 02:39
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.

ockam_vault_extern_error_t's definition/lack of documentation might encourage memory leaks.
2 participants