Bug 2044282 - glean-sym: Free data on the other side of FFI#3474
Bug 2044282 - glean-sym: Free data on the other side of FFI#3474badboy wants to merge 2 commits into
Conversation
9875ac2 to
d58386f
Compare
9842fc6 to
7b9758c
Compare
|
I've been testing it with these changes in appservices: mozilla/application-services@main...badboy:application-services:re-enable-glean-sym Basically recording a timing distribution along with the initialization (to make sure it's done early). |
This ensures remote `RustBuffers` are dropped by calling `ffi_glean_core_rustbuffer_free` instead of doing a local drop.
7b9758c to
a0d17e8
Compare
|
error log on the old glean-sym: |
|
successful run results in a ping like this one. see |
chutten
left a comment
There was a problem hiding this comment.
r+wc
...needs CHANGELOG? Or I guess it might be covered by the "EXPERIMENTAL" warning
| // SAFETY: | ||
| // * `src` is a newly created `Vec` with `reslen` capacity. | ||
| // * `dst` is a `Vec` pointer with size `reslen` | ||
| // * Both `src` (newly created `Vec`) and `dst` (a pinter obtained from a `Vec`) |
There was a problem hiding this comment.
| // * Both `src` (newly created `Vec`) and `dst` (a pinter obtained from a `Vec`) | |
| // * Both `src` (newly created `Vec`) and `dst` (a pointer obtained from a `Vec`) |
|
|
||
| let mut newvec = Vec::with_capacity(reslen); | ||
|
|
||
| // SAFETY: |
There was a problem hiding this comment.
Your safety note might be stale as it references src which doesn't exist.
| // * `ffi_glean_core_rustbuffer_free` is generated by `UniFFI` | ||
| // and accepts the `repr(C)` `RustBuffer` that we previously got via FFI. | ||
| unsafe { | ||
| let mut call_status = uniffi::RustCallStatus::default(); |
There was a problem hiding this comment.
Near as I can tell, default for RustCallStatus isn't unsafe and so it doesn't need to be in here.
| use std::sync::RwLock; | ||
| use std::sync::atomic::{AtomicUsize, Ordering}; | ||
|
|
||
| macro_rules! elog { |
There was a problem hiding this comment.
I'd like a comment here about the non-allocating logger
| unsafe fn dealloc(&self, ptr: *mut u8, _layout: Layout) { | ||
| unsafe { |
| let mut found = false; | ||
| for idx in 0..max_idx { | ||
| let val = map[idx]; | ||
| if val == ptr as usize { | ||
| found = true; | ||
| break; | ||
| } | ||
| } |
| elog!( | ||
| "%.*s: Trying to dealloc=%p. Pointer wasn't allocated here.", | ||
| self.name.len() as i32, | ||
| self.name.as_ptr(), | ||
| ptr | ||
| ); | ||
| std::process::abort(); |
There was a problem hiding this comment.
elog + abort is different from panic! in what way?
Unfortunately with the current UniFFI API this will require copying a bit more data.
The first commit adds a test. It will fail.
The second is trying to address it. The test should then succeed.