Skip to content

Bug 2044282 - glean-sym: Free data on the other side of FFI#3474

Open
badboy wants to merge 2 commits into
mainfrom
use-a-local-panicking-allocator-to-detect-when-data-is-freed-on-t/lsnmwwrnsxww
Open

Bug 2044282 - glean-sym: Free data on the other side of FFI#3474
badboy wants to merge 2 commits into
mainfrom
use-a-local-panicking-allocator-to-detect-when-data-is-freed-on-t/lsnmwwrnsxww

Conversation

@badboy
Copy link
Copy Markdown
Member

@badboy badboy commented Jun 2, 2026

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.

@badboy badboy force-pushed the use-a-local-panicking-allocator-to-detect-when-data-is-freed-on-t/lsnmwwrnsxww branch from 9875ac2 to d58386f Compare June 2, 2026 11:17
@badboy badboy force-pushed the use-a-local-panicking-allocator-to-detect-when-data-is-freed-on-t/lsnmwwrnsxww branch 2 times, most recently from 9842fc6 to 7b9758c Compare June 4, 2026 10:41
@badboy
Copy link
Copy Markdown
Member Author

badboy commented Jun 4, 2026

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).
Without the change here about freeing the data it crashes on my test phone.
With this change it works.

@badboy badboy marked this pull request as ready for review June 4, 2026 10:43
@badboy badboy requested a review from a team as a code owner June 4, 2026 10:43
@badboy badboy requested review from jeddai and removed request for a team June 4, 2026 10:43
badboy added 2 commits June 4, 2026 12:45
This ensures remote `RustBuffers` are dropped by calling `ffi_glean_core_rustbuffer_free` instead of doing a local drop.
@badboy badboy force-pushed the use-a-local-panicking-allocator-to-detect-when-data-is-freed-on-t/lsnmwwrnsxww branch from 7b9758c to a0d17e8 Compare June 4, 2026 10:45
@badboy badboy requested a review from chutten June 4, 2026 10:46
@badboy
Copy link
Copy Markdown
Member Author

badboy commented Jun 4, 2026

error log on the old glean-sym:

                 DEBUG  F  #00 pc 000000000004fbcc  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: ba489d4985c0cf173209da67405662f9)
                         F  #01 pc 0000000000040364  /apex/com.android.runtime/lib64/bionic/libc.so (scudo::die()+8) (BuildId: ba489d4985c0cf173209da67405662f9)
                         F  #02 pc 0000000000040b00  /apex/com.android.runtime/lib64/bionic/libc.so (scudo::ScopedErrorReport::~ScopedErrorReport()+32) (BuildId: ba489d4985c0cf173209da67405662f9)
                         F  #03 pc 0000000000040bc8  /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportHeaderCorruption(void*)+60) (BuildId: ba489d4985c0cf173209da67405662f9)
                         F  #04 pc 0000000000042328  /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+296) (BuildId: ba489d4985c0cf173209da67405662f9)
                         F  #05 pc 0000000000d656b0  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libmegazord.so (BuildId: 2325b56ad93051949290aedc64c5ce443df84a0b)
                         F  #06 pc 0000000000d63198  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libmegazord.so (BuildId: 2325b56ad93051949290aedc64c5ce443df84a0b)
                         F  #07 pc 0000000000f18a18  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libmegazord.so (BuildId: 2325b56ad93051949290aedc64c5ce443df84a0b)
                         F  #08 pc 0000000000eda2d0  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libmegazord.so (BuildId: 2325b56ad93051949290aedc64c5ce443df84a0b)
                         F  #09 pc 0000000000eb0624  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libmegazord.so (BuildId: 2325b56ad93051949290aedc64c5ce443df84a0b)
                         F  #10 pc 0000000000edfd64  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libmegazord.so (uniffi_ptr_places_fn_method_placesapi_new_connection+100) (BuildId: 2325b56ad93051949290aedc64c5ce443df84a0b)
                         F  #11 pc 000000000001404c  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libjnidispatch.so (BuildId: 8549526bbd95df90b51b87eaf518d627a449eb24)
                         F  #12 pc 0000000000010a68  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libjnidispatch.so (BuildId: 8549526bbd95df90b51b87eaf518d627a449eb24)
                         F  #13 pc 000000000000755c  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libjnidispatch.so (BuildId: 8549526bbd95df90b51b87eaf518d627a449eb24)
                         F  #14 pc 0000000000011080  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libjnidispatch.so (BuildId: 8549526bbd95df90b51b87eaf518d627a449eb24)
                         F  #15 pc 00000000000141e0  /data/app/~~ZwLBmNRC4JBdHCYsdLbV2A==/org.mozilla.fenix.debug-MwzMIccxsjGNr_ve_zZA2g==/lib/arm64/libjnidispatch.so (BuildId: 8549526bbd95df90b51b87eaf518d627a449eb24)
                         F  #16 pc 00000000002d9a44  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
                         F  #17 pc 00000000002d0164  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
<snip>

@badboy
Copy link
Copy Markdown
Member Author

badboy commented Jun 4, 2026

successful run results in a ping like this one.

see places_manager.run_maintenance_chk_pnt_time_temp

      "places_manager.run_maintenance_chk_pnt_time_temp": {
        "values": {
          "189812531": 3
        },
        "sum": 601430633
      },

Copy link
Copy Markdown
Contributor

@chutten chutten left a comment

Choose a reason for hiding this comment

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

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`)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
// * 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:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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 {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd like a comment here about the non-allocating logger

Comment on lines +77 to +78
unsafe fn dealloc(&self, ptr: *mut u8, _layout: Layout) {
unsafe {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Double-unsafe?

Comment on lines +82 to +89
let mut found = false;
for idx in 0..max_idx {
let val = map[idx];
if val == ptr as usize {
found = true;
break;
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

std::ops::ControlFlow?

Comment on lines +91 to +97
elog!(
"%.*s: Trying to dealloc=%p. Pointer wasn't allocated here.",
self.name.len() as i32,
self.name.as_ptr(),
ptr
);
std::process::abort();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

elog + abort is different from panic! in what way?

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants