Куда утекает память в read Rust?

Question

[Eugene Usachev]

У меня есть код:

#[inline(always)]
    pub(crate) fn get(&self, key: &BinKey) -> Option<BinValue>{
        let res = self.get_index_and_file(key); // 1
        if res.is_none() {
            return None;
        }

        let (file, info) = unsafe { res.unwrap_unchecked() };
        let mut buf = vec![0; info.0 as usize];
        file.read().unwrap().read_at(info.1, &mut buf).expect("failed to read");

        return Some(BinValue::new(buf.as_slice()));
    }

Под комментарием 1 он получает Option<(Arc < RwLock< File > >, (u64, u64))>. Дальше создаётся буфер нужного размера и туда записываются данные из файла. read_at читает файл с указанной позиции, заполняя буфер (можно заменить на seek + read, ошибка от этого не изменится). BinValue по сути создаёт что-то вроде вектора, и ошибка не в нём.

Если оставить код таким, то через 10 400 000 вызовов этой функции с заполнение буфера 100-байтовыми значениями утечёт примерно 1 ГБ памяти. Я провёл некоторые наблюдения и обнаружил, что память утекает только с вызовом функции file.read().unwrap().read_at(info.1, &mut buf). expect тут ни разу не сработал. Эти тесты проводились в Docker, если нужна дополнительная информация, спросите в комментариях.

Почему утекает память?

Answer 1

[Василий Банников]

TL;DR; 10400000 * 100 - это как раз почти гигабайт.
В текущем виде это компилироваться не должно, тк as_slice возвращает ссылку, а чтобы структура могла содержать в себе ссылку - нужно добавить лайфтайм в объявление структуры => этот же лайфтайм нужно будет указать в сигнатуре функции.
Сейчас ни того ни другого я не вижу и код не должен компилироваться по причине того что ты пытаешься вернуть ссылку на данные, которые живут только в рамках fn get.
Если же BinValue на самом деле владеет вектором, то это не утечка, а вполне ожидаемое поведение.
Смотри, где должен он дропаться в будущем.

1. Тут можно достаточно легко избавиться от unsafe:

let res = self.get_index_and_file(key);

if res.is_none() {
    return None;
}

let (file, info) = unsafe { res.unwrap_unchecked() };

Превращается в

let Some((file,info)) = self.get_index_and_file(key) else {
  return None;
};

2.
Вообще достаточно странный код.
На этой строке мы создали вектор - это ок. Он требует места в куче. Хотя странно, что info.0 у нас u64, а не usize
let mut buf = vec![0; info.0 as usize];

file.read().unwrap().read_at(info.1, &mut buf).expect("failed to read");

Тут мы файл прочитали. Возможно был смысл сделать BufRead, но не думаю, что он тут бы тут много чего сделал бы.
В остальном тут нет аллокаций.

3. А вот это уже выглядит реально подозрительно:
return Some(BinValue::new(buf.as_slice()));
Это вообще компилируется? Покажи, что из себя представляет BinValue.
По хорошему оно должно брать ownership над вектором.

Если оставить код таким, то через 10 400 000 вызовов этой функции с заполнение буфера 100-байтовыми значениями утечёт примерно 1 ГБ памяти

10 400 000 * 100 = как раз примерно гиг.
Если BinValue в действительности берёт ownership, то это вполне себе ожидаемое поведение, а не утечка.

4. Ещё я бы на всякий случай убрал #[inline(always)]

Comments

[Eugene Usachev]

Василий Банников, конечно, я могу показывать вам BinValue.

pub fn new(slice: &[u8]) -> Self {
        let len = slice.len();
        let new_slice: *mut u8;
        let size;
        unsafe {
            if len < 65535 {
                new_slice = Vec::<u8>::with_capacity(len + 2).leak().as_mut_ptr();
                *new_slice.offset(0) = len as u8;
                *new_slice.offset(1) = (len >> 8) as u8;
                size = 2;
            } else {
                new_slice = Vec::<u8>::with_capacity(len + 6).leak().as_mut_ptr();
                *new_slice.offset(0) = 255u8;
                *new_slice.offset(1) = 255u8;
                *new_slice.offset(2) = len as u8;
                *new_slice.offset(3) = (len >> 8) as u8;
                *new_slice.offset(4) = (len >> 16) as u8;
                *new_slice.offset(5) = (len >> 24) as u8;
                size = 6;
            }
            ptr::copy_nonoverlapping(slice.as_ptr(), new_slice.offset(size), len);
        }
        BinValue {
            ptr: new_slice
        }
    }

Ниже написано:

impl Drop for BinValue {
    fn drop(&mut self) {
        let len = self.len();
        let size = if len < 65535 { 2 } else { 6 };
        unsafe {
            drop(Vec::from_raw_parts(self.ptr, len + size, len + size));
        }
    }
}

Суть этого кода в том, чтобы вместо 16 байт (8 на указатель и 8 на длину) использовать 10-14 (8 на указатель + 2-6 на длину). Но у меня есть другие части кода, которые используют BinValue и не содержат утечек памяти.

Я тоже подумал на этот участок кода, но ошибка не там. Я пробовал заполнить его без чтения из файла и память не утекала.

[Василий Банников]

Eugene Usachev,
1. ух, unsafe да ещё и Vec::leak
Документация намекает, что так делать не нужно.

Consumes and leaks the Vec, returning a mutable reference to the contents, &'a mut [T]. Note that the type T must outlive the chosen lifetime 'a. If the type has only static references, or none at all, then this may be chosen to be 'static.

As of Rust 1.57, this method does not reallocate or shrink the Vec, so the leaked allocation may include unused capacity that is not part of the returned slice.

This function is mainly useful for data that lives for the remainder of the program’s life. Dropping the returned reference will cause a memory leak.

Если честно, я не понимаю что тут в new у вас происходит и зачем это нужно.
Если вы хотите разобрать Vec на части, чтобы потом собрать обратно - надо использовать into_raw_parts или брать отдельно длину, капасити, и сырой указатель и вызывать forget.
Ибо capacity может быть больше чем len, даже если не было реаллокаций и ты указал capacity при создании.

2. А в какой момент Drop должен быть вызван? Куда потом этот BinValue отправляется?

[Eugene Usachev]

Василий Банников, 1, мне недостаточно знаний, чтобы переписать это без unsafe. 2 Drop точно вызывается (это я тоже проверил). Я возвращаю BinValue выше, где записываю его в буфер, после чего он и исчезает.

[Василий Банников]

Eugene Usachev,

1, мне недостаточно знаний, чтобы переписать это без unsafe.

Скажите, что именно вы тут делаете и я подскажу

[Eugene Usachev]

Василий Банников, я принимаю срез. Дальше я аллоцирую память на размер среза + размер под его длину (2-6 байт). Мне нужно, чтобы Rust не очистил эту память за меня, так как я имею гарантию, что сам очищу память, когда это будет нужно. Если убрать leak, я встречаю двойное освобождение памяти.

[Василий Банников]

Окей. Зачем тебе отдельно записывать длину, если слайс и так по определению хранит в себе длину?
Почему бы тебе не владеть тупо Vec-ом?
Если тебе нужно выделить место под N байт, то зачем делать это через Vec, когда ты можешь напрямую обращаться к аллокатору и вызывать allocate / deallocate?

[Eugene Usachev]

Василий Банников, потому что я храню слишком много таких вот BinValue. Эти 4-6 сэкономленных байт имеют значение.

[Василий Банников]

Eugene Usachev, покажи ещё, как выглядит функция len у BinValue

[Eugene Usachev]

Василий Банников,

#[inline(always)]
    pub fn len(&self) -> usize {
        let mut l;
        unsafe {
            // first byte is length
            l = (*self.ptr) as usize | (*self.ptr.offset(1) as usize) << 8;
            if l < 65535 {
                return l;
            }
            return (*self.ptr.offset(2) as usize) | (*self.ptr.offset(3) as usize) << 8 | (*self.ptr.offset(4) as usize) << 16 | (*self.ptr.offset(5) as usize) << 24;
        }
    }

[Василий Банников]

Eugene Usachev, miri говорит, что у тебя UB:

error: Undefined Behavior: attempting a write access using <3565> at alloc1400[0x0], but that tag does not exist in the borrow stack for this location

На строке, где
*new_slice.offset(0) = len as u8;

Сейчас разберусь, что это значит и имеет ли это отношение к проблеме.
Формально, UB может к этому приводить.

[Eugene Usachev]

Василий Банников, этот код был покрыт тестами ещё давно. Ошибок он ни в Windows, ни в любом Docker-контейнере не содержит. Память утекает не в этой строчке (у меня есть почти идентичный код, только без чтения из файла, и он работает корректно; все тесты успешно сдаются; методом перебора кода построчно было найдено, что ошибка именно в строке "file.read().unwrap().read_at(info.1, &mut buf).expect("failed to read")")

[Василий Банников]

Eugene Usachev, в общем сильно не переписывал, но по крайней мере теперь UB нет и код выглядит чуть понятнее:

pub struct BinValue {
    ptr: *mut u8,
}

impl BinValue {
    #[inline(always)]
    pub fn len(&self) -> usize {
        let len: u16 = unsafe { ptr::read_unaligned(self.ptr.cast()) };
        if len < 0xFFFFu16 {
            return len as usize;
        }
        let len: u32 = unsafe { ptr::read_unaligned(self.ptr.offset(2).cast()) };
        len as usize
    }

    pub fn new(slice: &[u8]) -> Self {
        let len = slice.len();
        let new_slice: *mut u8;
        let size;
        unsafe {
            if len < 65535 {
                // [u16, [u8]]
                let mut vec = Vec::<u8>::with_capacity(len + 2);
                assert_eq!(len + 2, vec.capacity());
                new_slice = vec.as_mut_ptr();
                std::mem::forget(vec);
                ptr::write_unaligned(new_slice.cast(), len as u16);
                size = 2;
            } else {
                // [FF, FF, u32, [u8]]
                let mut vec = Vec::<u8>::with_capacity(len + 6);
                assert_eq!(len + 6, vec.capacity());
                new_slice = vec.as_mut_ptr();
                std::mem::forget(vec);
                ptr::write_unaligned(new_slice.cast(), 0xFFFFu16);
                ptr::write_unaligned(new_slice.offset(2).cast(), len as u32);
                size = 6;
            }
            ptr::copy_nonoverlapping(slice.as_ptr(), new_slice.offset(size), len);
        }

        BinValue {
            ptr: new_slice
        }
    }
}

impl Drop for BinValue {
    fn drop(&mut self) {
        let data_len = self.len();
        let len_size = if data_len < 65535 { 2 } else { 6 };
        let buf_len = data_len + len_size;
        unsafe {
            drop(Vec::from_raw_parts(self.ptr, buf_len, buf_len));
        }
    }
}

Проблему твою воспроизвести не смог - память вполне успешно освобождается.
(код такой)

use std::ptr;
use std::thread::sleep;
use std::time::Duration;

fn main() {
    let arr: &[u8] = &[0; 128];

    println!("Data is not allocated yet!");
    let mut bin_values = Vec::with_capacity(100);
    for _ in 0..100 {
        let val = BinValue::new(arr);
        assert_eq!(val.len(), 128);
        bin_values.push(val);
    }
    println!("Data allocated!");

    let sum: usize = bin_values.iter().map(|x| x.ptr as usize).sum();
    println!("Side effect! {sum}");
    sleep(Duration::from_secs(10));
    drop(bin_values);
    println!("Data deallocated!");
    sleep(Duration::from_secs(60));
}

[Василий Банников]

Eugene Usachev, каким образом было определено, что утекает именно при чтении из файла?

[Eugene Usachev]

Василий Банников, я попробовал применить ваши изменения. Разницы, ожидаемо, нет. Память утекает где-то в reat_at. Я прошёлся по всем вызовам reat_at, но не нашёл там ничего интересного (4 вызова функций с одинаковыми параметрами, последняя вызывает syscall на unix), но именно там пропадает память.

[Василий Банников]

Eugene Usachev,

каким образом было определено, что утекает именно при чтении из файла?

[Eugene Usachev]

Василий Банников, во-первых, у меня есть почти идентичная функция, в которой нет работы с файлами и память не утекает. Во-вторых, я начал заменять части функции (вместо чтения сам заполнил буфер, вернул другой тип, не вызывал блокировки и так далее) и обнаружил, что при комментировании этой строки и её симуляции не происходит утечка.

Я подумал, что ошибка связана с блокировкой (хотя это тоже странно). Для этого я вызвал блокировку, закомментировал работу с файлом и воспользовался значением из кортежа, чтобы Rust не убрал функцию после компиляции. Утечка всё ещё не произошла. Так как у меня стабильный Rust, я не могу использовать black_box, поэтому не могу выражать уверенность в достоверности этого теста.

Дальше я заменил работу с файлом на типичный seek и read и посмотрел. Утечка снова появилась!

Я подумал, что, может, я неправильно симулировал заполнение буфера. Попробовал заполнить более правдоподобно и проверить, что его длина нужного размера. Этот тест тоже не вызвал утечку.

А дальше у меня закончились идеи, где ещё может прятаться ошибка.

[Василий Банников]

Eugene Usachev, У меня появилась идея. А что, если объект File таки имеет внутри буфер и чтение происходит буферизовано? Если не на стороне программы, то хотябы на стороне ОС?
Это бы вполне могло объяснить утечку памяти.
Тогда имеет смысл дропнуть файл сразу, как только он стал не нужен.
Чтобы проверить это - имеет смысл запустить профайлинг и посмотреть, чем вообще память занята.

Я подумал, что ошибка связана с блокировкой (хотя это тоже странно).

Это не странно, тк синхронизация требует O(N) по памяти, емнип, но не думаю, что тут оно виновато.

Так как у меня стабильный Rust, я не могу использовать black_box, поэтому не могу выражать уверенность в достоверности этого теста.

ради тестов можно и найтли поставить.

[Eugene Usachev]

Василий Банников, попробовал сразу сбрасывать файл. Производительность, очевидно, значительно просела, но и утечка никуда не делась. С профайлером мысль хорошая, попробуй научится профайлить Docker-контейнеры.

[Василий Банников]

Eugene Usachev, а оно только в докере возникает?

[Eugene Usachev]

Василий Банников, на Windows эта часть приложения не поддерживается, а именно эта ОС стоит на моём компьютере. В целом, приложение и не разрабатывается для использования на таких тяжёлых ОС, поэтому это не является проблемой для меня.

[Дмитрий Беляев]

Василий Банников, у Option есть try оператор, так что вместо:

let Some((file,info)) = self.get_index_and_file(key) else {
  return None;
};

достаточно написать: let (file,info) = self.get_index_and_file(key)?;