Есть ли Undefined Behavior в Rust?

Если вы никогда не сталкивались с Rust-ом, а слышали, что он помогает избежать Undefined Behavior (UB), то отчасти это так. Некоторые делят язык Rust на 2 части: safe и unsafe. Я бы поделил на 4 части: safe, unsafe, const и async. Но нас интересуют safe и unsafe.

Получить UB в Rust-е не сложно, нужно открыть документацию и найти любой метод, помеченный unsafe, например, get_unchecked у Vec. Метод позволяет без проверки границ получить значение из динамического массива. А есть ли UB в safe-подмножестве языка? Есть. Он возможен из-за бага (проблемы) в компиляторе Rust, который живет с 2015 года.

Проблема

Рассмотрим следующий код:

fn helper<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }  pub fn make_static<'a, T>(input: &'a T) -> &'static T {     let f: fn(_, &'a T) -> &'static T = helper;     f(&&(), input) }  fn main() {     let memory = make_static(&vec![0; 1<<20]);     println!("{:?}", memory); }

Результат в дебаге и релизе различается, но в том и том варианте появляется ошибка Segmentation fault.

Простое объяснение: Ссылка на временный объект становится статической, то есть компилятор считает, что значение по статической ссылке живет до конца программы, но на самом деле временный вектор очищается после вызова make_static и дальше происходит обращение к освобожденной памяти.

Дисклеймер: Дальше идет техническая часть специфичная для Rust-а.

..  let _1: &std::vec::Vec<i32>; let _2: &std::vec::Vec<i32>; let _3: std::vec::Vec<i32>;  ..  bb2: {     _2 = &_3;     _1 = make_static::<Vec<i32>>(_2) -> [return: bb3, unwind: bb8]; }  bb3: {     drop(_3) -> [return: bb4, unwind continue]; }  bb4: {     _15 = const _;     _9 = _15 as &[&str] (PointerCoercion(Unsize));     _14 = &_1;     _13 = core::fmt::rt::Argument::<'_>::new_debug::<&Vec<i32>>(_14) -> [return: bb5, unwind continue]; }  bb5: {     _12 = [move _13];     _11 = &_12;     _10 = _11 as &[core::fmt::rt::Argument<'_>] (PointerCoercion(Unsize));     _8 = Arguments::<'_>::new_v1(move _9, move _10) -> [return: bb6, unwind continue]; }  bb6: {     _7 = _print(move _8) -> [return: bb7, unwind continue]; }

Детальное объяснение

Вспомним, что такое lifetimes. В Rust тип &'a T означает ссылку на тип T, которая действительна для времени жизни 'a. Между временами жизни могут быть отношения. Такие отношения используют механизмы подтипов (Subtyping) и вариантности (Variance). Например, 'a: 'b (произносится как «‘a переживет ‘b»), если время жизни 'a содержит все время жизни 'b. Ссылки на ссылки &'a &'b T допустимы, но только если 'b: 'a, так как время жизни ссылки не должно превышать время жизни ее содержимого.

Существует также самое длинное время жизни 'static, такое, что 'static: 'a для любого времени жизни 'a. Такое преобразование и позволяет получить ошибку.

Контравариантность позволяет передавать аргументы с большим временем жизни, чем требуется функции, что позволяет использовать helper в типе fn(_, &'a T) -> &'static T.

На самом деле исходный вариант проблемы был решен. Изначально там был тип fn(&'static &'a (), &'a T) -> &'static T , но замена типа первого аргумента на placeholder (нижнее подчеркивает) позволяет пропустить работу type checker-а.

Вместо вывода

Надеюсь, данную ошибку смогут исправить в 2024 году, так как над этим активно ведутся работы. Были предложены следующие варианты решения:

• Запретить контрвариантность в функциях;

• Замена trait solver-а для реализации автоматического расширения типа for<'a, 'b> fn(&'a &'b (), &'b T) -> &'a Tдо for<'a, 'b> where<'b:'a, T:'b> fn(&'a &'b (), &'b T) -> &'a T;

Чтобы самим не попасться на подобную ловушку, советую для вложенных ссылок явно писать ограничения в where-блоке для времен жизни.

Ссылки

• fake-static крейт

• Implied bounds on nested references + variance = soundness hole

• Counterexamples in Type Systems

• Tracking Issue for -Znext-solver 

• Officially announcing the types team

• RFC Well formed and variance