Прим. пер.: Кто-то должен был сделать перевод этой статьи, несмотря на то, что она достаточно стара (2015 год), поскольку она показывает очень важную особенность работы с памятью в Rust — с помощью безопасного (не помеченного как unsafe ) кода можно создавать утечки памяти . Это должно отрезвлять народ, верящий во всемогущность borrow checker'а.

Спойлер — внутри про невозможность отслеживания циклических ссылок, а также старые болезни некоторых типов из std , на момент перевода благополучно вылеченные.

Несмотря на наличие в Книге главы про безопасный код (спасибо за напоминание ozkriff), а также разъяснительной статьи русскоязычного сообщества (спасибо за напоминание mkpankov), я решил выполнить перевод для наглядной демонстрации серьезности непонимания возможностей управления памятью Rust.

Вероятнее всего, данная статья ранее не переводилась по причине весьма специфических терминов автора, которые НЛО в тираж не пропустит. По этой причине перевод не совсем дословный.

Утечкокалипсис

Словно гром посреди ясного неба, баг с циклическими ссылками в std::thread::JoinGuard поверг сообщество в пучину экзистенциального ужаса. Если вы следите за новостями и уже в курсе утечкокалипсиса, данную секцию можете смело пропускать и переходить к следующей. Если вы следите за моими комментариями в сообществе, то в принципе вам что-либо новое здесь читать нечего, можете смело закрывать окно и возвращаться к дальнейшему изучению моих комментариев.

Итак, баг:

С помощью циклических ссылок можно упустить JoinGuard, вследствие чего поток области видимости (scoped thread) может получить доступ к уже освобожденной области памяти.

Крайне серьезное заявление, поскольку все используемые API помечены как безопасные, что (по изначальному ожиданию авторов языка — прим.пер.) обязано исключить такое поведение безопасного кода в принципе.

Основной фокус приходится на API thread::scoped , который создает поток с доступом к окну стека другого потока, безопасность которого гарантирована компилятором статически. Идея в основе безопасности состоит в JoinGuard , возвращаемом thread::scoped , чей деструктор блокирует выполнение ожидающего и владеющего стеком потока; соответственно, ничто более, переданное в ожидаемый поток, не может пережить данный JoinGuard . Это позволяет реализовывать довольно полезные вещи вроде:

use std::vec::Vec; use std::thread; fn increment_elements(slice: &mut [u32]) { for a in slice.iter_mut() { *a += 1; } } fn main() { let mut v = Vec::new(); for i in (0..100) { v.push(i); } let mut threads = Vec::new(); for slice in v.chunks_mut(10) { threads.push(thread::scoped(move || { increment_elements(slice); })); } // JoinGuard'ы `threads` здесь дропаются, и `main` будет заблокирован // пока не завершится последний из дочерних потоков }

Здесь выполняется некая полезная работа для каждого из десяти элементов массива в отдельном потоке (ну, типа как. Здесь просто пример, представьте там полезную нагрузку сами.). Магическим образом Rust способен статически гарантировать безопасность доступа к данным даже не зная, что именно происходит в дочерних потоках! Ему нужно просто видеть массив (Vec) JoinGuard'ов потоков, которые заимствуют v , соответственно v не может умереть раньше, чем потоки завершатся. (А если точнее, Rust и про массив не знает особо, ему достаточно, что threads заимствует v , даже если threads вообще пуст).

И это очень прикольно. И увы, неверно.

Предполагается, что деструкторы (здесь и далее — реализации Drop — прим.пер.) гарантированно исполняются в безопасном, не помеченном unsafe коде. Что уж говорить, ваш покорный слуга, как и многие в сообществе выросли с верой в данный постулат. В конце концов, у нас даже есть отдельная функция, которая специально удаляет связь с элементом без вызова деструктора, mem::forget , и во имя данного постулата она намеренно помечена как unsafe !

Как оказалось, это всего лишь отголоски старых вариантов API. На самом деле mem::forget в стандартной библиотеке в некоторых местах используется в безопасном коде. И если почти все из этих мест были позже отнесены как ошибки имплементации, то одно оставшееся достаточно фундаментально. Это rc::Rc .

Rc у нас — умный указатель со счетчиком ссылок. Он весьма прост — клади в конструктор Rc::new данные для разделения между несколькими ссылками да пользуйся. Клонируешь ( clone() ) Rc — счетчик увеличивается. Удаляешь ( drop() ) клон — счетчик уменьшается. Все работает только за счет borrow checker'а — отслеживание времен жизни гарантирует, что ссылки на данные освобождены до момента удаления Rc, через который они (ссылки) получены.

Сам по себе Rc вполне торт — благодаря принципу работы счетчика мы работает только со ссылками на внутренности, сами данные остаются на месте в плане освобождения памяти, прочесть что-то вне этой памяти невозможно… кроме случаев внутренней изменяемости (internal mutability). Хотя раздача копий ссылок на данные в Rust подразумевает неизменяемость (данных, не ссылок), сами данные все же возможно изменять, в качестве исключения из правил. Для этих целей служит Cell , чьи внутренности можно менять даже в случае множественного доступа. Собственно, поэтому типы Cell помечены как непотокобезопасные. Для потоков есть sync::Mutex .

А теперь смешаем Rc с drop и напишем безопасный forget :

fn safe_forget<T>(data: T) { use std::rc::Rc; use std::cell::RefCell; struct Leak<T> { cycle: RefCell<Option<Rc<Rc<Leak<T>>>>>, data: T, } let e = Rc::new(Leak { cycle: RefCell::new(None), data: data, }); *e.cycle.borrow_mut() = Some(Rc::new(e.clone())); // Привет, цикл ссылок }

Похоже на лютую ересь. Вкратце, можно создавать циклически зависимые считаемые ссылки с помощью Rc и RefCell . Итогом будет тот факт, что деструктор типа, положенного внутрь Leak<T> никогда не будет вызван, хотя ссылок на Rc у нас больше нет. В принципе невызов деструктора сам по себе не страшен, можно же завершить программу извне или работать в бесконечном цикле. Но не в данном случае — Rc нам сказал, что вызывал деструктор. Это даже можно проверить:

fn main() { struct Foo<'a>(&'a mut i32); impl<'a> Drop for Foo<'a> { fn drop(&mut self) { *self.0 += 1; } } let mut data = 0; { let foo = Foo(&mut data); safe_forget(foo); } // проверяем вдоль и поперек, что ссылок на данные нигде нет // иначе строка внизу упадет при компиляции data += 1; println!("{:?}", data); // а тут 1, а должно быть 2 }

Оно работает. Теперь надо бы разобраться в проблеме из исходного тикета, вызвавшего панику. Уменьшим пример из тикета до следующего:

fn main() { let mut v = Ok(4); if let &mut Ok(ref v) = v { let jg = thread::scoped(move || { println!("{}", v); // чтение из дочернего потока }); safe_forget(jg); // JoinGuard забыт, деструктор не вызовется, join бит } *v = Err("foo"); // одновременное изменение данных из нескольких потоков - гонка }

Мы раскрыли неопределенное поведение.

И это бесспорно дыра в стандартной библиотеке Rust, поскольку невозможность use-after-free и гонок данных вроде как обещана и статически гарантирована, а мы тривиальным примером добились и того, и другого. Возникает вопрос — что именно сделано неверно. Исходный тикет предсказуемо бросает тень на thread::scoped , так как создан разработчиком компилятора, который 100% в курсе возможности утечки деструктора из "безопасного" кода.

Это немедленно породило волну фрустрации в сообществе — до этого момента они видели утечки только в unsafe . thread::scoped стабилизирован. mem::forget помечен как unsafe , только лишь потому, что никак, никогда, ни в коем случае и совсем нельзя течь не из-под unsafe !

После разбирательства в истоках бага было выявлено стечение обстоятельств:

Шаринг счетчиком ссылок

Внутренняя изменяемость

Rc принимает нестатичные данные (не 'static )

при которых, и никак более, баг проявляется. Это немедленно привело к появлению личностей (увы, меня тоже), требующих в той или иной форме запрета существания любых комбинаций данных обстоятельств на уровне компилятора. Чтобы вы понимали уровень отчаяния — даже появился настойчивый запрос на внутренний типаж Leak , помечающий возможность утечки деструктора в safe.

Внимание. Релиз 1.0 через три недели, внедрять что-либо вышеупомянутое просто нет времени. Выводы сделаны единственно верные — вынуть mem::forget из unsafe (поскольку он ничего скрыто опасного не делает), переделать thread::scoped . Соответствующие RFC:

Обратите внимание: Rust никогда не гарантировал отсутствие утечек в принципе . Утечки, равно как и гонки данных — не имеющий четких границ концепт, потому фактически непредотвратимый. Если сложить что-то в HashMap и никогда его не спросить — тоже в своем роде утечка. Аллоцировать что-то на стеке, после чего запустить бесконечеый цикл — туда же. Любой случай складывания данных в кучу с последующим забыванием об их существовании это самая что ни на есть утечка, которая почему-то именно в данном виде вызывает у людей панический ужас. Ошибкой можно считать данные, у которых забыли вызвать деструктор во время обычного "безопасного" выполнения, потому что с точки зрения статического анализа этих данных не существует.

Что делать?

Таким образом, я был удручен и растерян. Работа с коллекциями в моем понимании всегда подразумевала гарантированное выполнение деструкторов. Были прекрасные возможности как собрать дескриптор для сколь угодно сложного и зависимого типа, действующий прозрачно, но прячущий все внутренности, так и разобрать его корректно при удалении. При работе с временами жизни Rust это гарантировало, однако, что неопределенное состояние данных типа вне этого дескриптора статически невыделяемо! То есть Rust еще более беспечен, чем C!

Каноничный этому пример — Vec::drain_range :

// Нам правда нужны все эти поля? Хз? // Пусть пока полежат для примера. struct DrainRange<'a, T> { vec: &'a mut Vec<T>, num_to_drain: usize, start_pos: usize, left: *mut T, right: *mut T, } impl<T> Vec<T> { // Производит итератор, вынимаюший элементы из `self[a..b]` // Поправка: b не включен в множество, смотри нотацию Rust range fn drain_range(&mut self, a: usize, b: usize) -> DrainRange<T> { assert!(a <= b, "invalid range"); assert!(b <= self.len(), "index out of bounds"); DrainRange { left: self.ptr().offset(a as isize), right: self.ptr().offset(b as isize), start_pos: a, num_to_drain: b - a, vec: self, } } } impl<'a, T> Drop for DrainRange<'a, T> { fn drop(&mut self) { // Поудалять все лишнее for _ in self { } let ptr = self.vec.ptr(); let backshift_src = self.start_pos + self.num_to_drain; let backshift_dst = self.start_pos; let old_len = self.vec.len(); let new_len = old_len - self.num_to_drain; let to_move = new_len - self.start_pos; unsafe { // Сдвинуть все элементы назад! ptr::copy( ptr.offset(backshift_src as isize), ptr.offset(backshift_dst as isize), to_move, ); // Сказать Vec, что у него используется только эта часть элементов self.vec.set_len(new_len); } } } // Для законченности примера impl<'a, T> Iterator for DrainRange<'a, T> { type Item = T; fn next(&mut self) -> Option<T> { if self.left == self.right { None } else { unsafe { let result = Some(ptr::read(self.left)); // Игнорируем size_of<T> == 0 для простоты self.left = self.left.offset(1); result } } } } impl<'a, T> DoubleEndedIterator for DrainRange<'a, T> { fn next_back(&mut self) -> Option<T> { if self.left == self.right { None } else { unsafe { // Игнорируем size_of<T> == 0 для простоты self.right = self.right.offset(-1); Some(ptr::read(self.right)) } } } }

Тут даже корректно работает unwind, класс! А деструктор не работает, смотрите:

fn main() { let vec = vec![Box::new(1)]; { let drainer = vec.drain_range(0, 1); // вынуть и дропнуть `box 1` - память, куда он указывает, очистится drainer.next(); safe_forget(drainer); } println!("{}", vec); // use-after-free памяти, куда указывал `box 1` }

Не круто. Я порылся в коде коллекций стандартной библиотеки на предмет чего-то, что надеется на деструктор для обеспечения безопасности, и, к счастью, ничего не нашел (что, безусловно, совсем не значит, что его там нет). Если конкретней, искал я нечто, укладывающееся в следующую иерархию гадостей текущего деструктора:

Деструктора нет — нет утечки: примитивы, указатели Утечка системных ресурсов — не особо и проблема: большинство коллекций и умных указателей вокруг примитивов, у которых при утечке просто расходуется куча Обычная утечка деструктора — неприятно, но не смертельно: коллекции и умные указатели вокруг структур Мир в неопределенном, но безопасном состоянии — уверенный "пыщь" в ногу: RingBuf::drain должен чистить коллекцию после того, как его ссылка его drain-итератора заканчивает жить, но это в данный момент гарантировано только деструктором. Сама коллекция при этом консистентна. Мир сломан — неприемлемо: вышеупомянутый Vec::drain_range

В общем случае, следует отодвигать зависимость от деструктора настолько дальше согласно этой иерархии, насколько практически возможно, с исключением кода из последней категории из всех API, не помеченных unsafe .

Данная иерархия базируется на предположении, что текущий деструктор в работающей программе — баг. Ни более, ни менее, код приложения обязан предполагать, что в произвольном его месте или при адекватных в нем условиях утечек не будет. В качестве обычной практики в Rust сторонние библиотеки единолично обязаны подтверждать невозможность утечек.

Факт наличия кода, возможно провоцирующего утечку, в API, наподобие Rc , не должен расцениваться как баг API или его реализации. Более того, если утечка возможна лишь при определенных, созданных конечным пользователем условиях. Несмотря на извлечение mem::forget из unsafe и возможность его вызовов в безопасном коде, в общих случаях необходимо помнить, что последствия его вызова небезопасны.

Rust может заставить обделаться неприятно удивить

(скорее всего этот участок и есть причина, почему данная статья мало цитируется — прим.пер.)

Как же нас обезопасить использование Vec::drain_range и передвинуть его выше по иерархии? Добавлением следующей строки в конструктор drain_range . Все вот так просто!

// Убеждаем Vec, что он пуст за пределами минимальной границы. unsafe { self.set_len(a); }

Теперь, если DrainRange утечет, у нас утекут деструкторы элементов, которые нужно повынимать, поскольку мы совсем потеряли сдвигаемые в начало вектора значения. Это вполне относимо к категории "неопределенное, но безопасное состояние", ну, еще прибавляются возможные и разнообразные другие утечки. Все еще хреново, но уже большой прогресс относительно use-after-free, происходившего ранее!

Это то, что я называю паттерном "Уж Лучше Обделаться" (Pre-Poop Your Pants (PPYP) pattern) — спасти ситуацию в конструкторе хотя бы частично, если деструктор не включится. Почему такое стремное название? Мм. Я привык представлять жизненный цикл между конструктором и деструктором как процесс пищеварения. Что-то можно съесть (конструктор), обработать и сходить в туалет (деструктор). Если деструктор пропал, туалет уже не светит никогда. В зависимости от жизненной ситуации (деструктора), возможны разнообразные последствия:

Типы сломаны на структурном уровне — все, конец, уже никто никуда не ходит. Где тут хирург? Типы вроде целы, но система уже ими испорчена, и в любой момент сломается, если запор затянется Типы большие и сложные — Есть шанс, что внутри ничего неприятного нет Типы-безопасные лекарства — При несоблюдении техники безопасности могут показать вам вертолет и привести к более худшим последствиям, но при определенных условиях это можно пережить и вернуться в строй. Типы-опасные лекарства — возможны передозировка и летальный исход, должны быть максимально проконтролированы.

Собственно, паттерн "Уж Лучше Обделаться" является следующим отклонением от обычного процесса пищеварения: если вы что-то неожиданное съели, будьте готовы к "преждевременным неприятностям". Обычно неприятности не настигают, и вы успеваете дойти до туалета согласно плану его посещения. Но если они все же настигли, уж лучше обделаться и засмущаться, чем упасть в бессознании и очнуться на столе у хирурга. Паттерн выделяет следующее:

Это неоптимальный компромисс: никому не хочется очутиться в такой ситуации, но это не наихудшее, что может произойти

Это незаметно, если происходит согласно плану: если вы предвидели это и специально ушли в глухой лес чтобы увидеть медведя — никто ж ничего не узнает. Ничего не было ^^

Это не всегда неизбежно: на практике всякая фигня плотно перемешана с нормальными обрабатываемыми данными, и, возможно, в вашем конкретном случае возможно просто не жрать всякую фигню (типа thread::scoped )

) Это бессмысленно и бесполезно само по себе: наследник и плод уязвимого шаблона RAII.

Это забавно: я написал про штаны полные конфуза, а вы это прочли (нет, не забавно — прим.пер.)