Início / coding / Perguntas / 79424647
Accepted
realwangliqiu
Asked: 2025-02-09 17:08:29 +0800 CST

Por que os testes unitários não entram em pânico por causa de um ponteiro pendurado?

  • 772
fn dangle() {
    fn get_str<'a>(s: *const String) -> &'a str {
        unsafe { &*s }
    }
    
    let s = String::from("hello");
    let dangling = get_str(&s);
    drop(s);
    println!("Invalid str: {}", dangling);
}

#[test]
fn test() {
    dangle();  // it should panic, but does not
}

fn main() {
    dangle();  // panics
}

A main()função entra em pânico, como eu esperava. Mas por que a test()função roda com sucesso?

rust

2 respostas

  1. Best Answer

    Conforme descrito nesta página , seu uso de nãounsafe é sólido (isso foi feito de propósito na pergunta) e, consequentemente, leva a um comportamento indefinido .

    Comportamento indefinido não significa que o código necessariamente falhará ou entrará em pânico. Pelo contrário, ele pode fazer qualquer coisa , inclusive funcionar perfeitamente! No meu computador, o programa principal não entra em pânico; ele simplesmente exibe uma string estranha e, ao testá-lo, também não entra em pânico. Mesmo que, no meu computador, o ponteiro não aponte para um endereço inacessível após drop(), os bytes neste endereço foram reutilizados para outra coisa, o que parece incorreto quando enviado para a saída padrão. Este comportamento pode mudar de tempos em tempos, dependendo de qualquer coisa no sistema (o sistema, a versão do compilador...).

    É por isso que códigos inseguros devem ser evitados; só podemos detectar e consertar um problema por acaso (se ele exibir um comportamento incorreto óbvio, como entrar em pânico). Se, por outro lado, o problema simplesmente causar corrupção de dados, ele pode ser detectado muito mais tarde durante a execução, e seria muito difícil descobrir qual foi a causa real do problema (ponteiro pendurado aqui). Essa situação é bem comum em C. O Rust seguro previne que essas armadilhas aconteçam; o Rust inseguro exige que o desenvolvedor mantenha certas garantias.

    • 6

  2. O que @prog-fh diz.

    Só queria acrescentar que, ao trabalhar com unsafecódigo, é altamente recomendável usá-lo miridurante os testes.

    mirié um linter que tenta detectar especificamente código não confiável. Não é garantido que ele encontre tudo, mas ele é muito bom nisso.

    Para verificar seu código com miri, execute:

    cargo +nightly miri test

    Então, você obtém o seguinte erro:

    error: Undefined Behavior: constructing invalid value: encountered a dangling reference (use-after-free)
    --> ~\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\core\src\fmt\mod.rs:2653:1
     |
2653 | fmt_refs! { Debug, Display, Octal, Binary, LowerHex, UpperHex, LowerExp, UpperExp }
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ constructing invalid value: encountered a dangling reference (use-after-free)
     |
     = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
     = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
     = note: BACKTRACE on thread `test`:
     ...
note: inside `dangle`
    --> src\main.rs:9:5
     |
9    |     println!("Invalid str: {}", dangling);
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `test`
    --> src\main.rs:14:5
     |
14   |     dangle(); // it should panic, but does not
     |     ^^^^^^^^
note: inside closure
    --> src\main.rs:13:10
     |
12   | #[test]
     | ------- in this procedural macro expansion
13   | fn test() {
     |          ^
     = note: this error originates in the macro `fmt_refs` which comes from the expansion of the attribute macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
    • 3

relate perguntas