manager - ¿Cómo depuro una prueba de carga fallida en GDB?

https tag manager

Question

Tengo una prueba de carga fallida:

$ cargo test
[snip]
    Running target/gunzip-c62d8688496249d8

running 2 tests
test test_extract_failure ... FAILED
test test_extract_success ... ok

failures:

---- test_extract_failure stdout ----
        task ''test_extract_failure'' panicked at ''assertion failed: result.is_err()'', /home/dhardy/other/flate2-rs/tests/gunzip.rs:19



failures:
    test_extract_failure

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured

task ''<main>'' panicked at ''Some tests failed'', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libtest/lib.rs:250

¿Cómo ejecuto la prueba fallida en un depurador como GDB?

Esta debería ser una pregunta general, pero para aquellos que quieran volver sobre mis pasos, instale una compilación Rust nocturna reciente y:

git clone https://github.com/dhardy/flate2-rs.git
git checkout 24979640a880
cd flate2-rs
cargo test

Answer 1

Puede obtener un binario de prueba para filtrar las pruebas que ejecuta pasándole argumentos adicionales; La carga expone esto directamente, también. Por lo tanto, cargo test test_extract_failure solo ejecutará ese caso específico. (Esto es conveniente si tiene otras pruebas que se asustan y se espera que fallen, para que no llamen a la función rust_panic que estoy a punto de mencionar, dejando solo la llamada ofensiva).

Para utilizar gdb, deberá ejecutar el binario de prueba directamente (si usa Cargo, se ejecuta en un subproceso y, por lo tanto, gdb no detectará pánicos en su interior). Cargo le indica el nombre del archivo, target/gunzip-c62d8688496249d8 . Puede ejecutar esto directamente con --test para que sea una ejecución de prueba:

$ target/gunzip-c62d8688496249d8 --test test_extract_failure
running 1 test
test test_extract_failure ... FAILED

failures:

---- test_extract_failure stdout ----
        task ''test_extract_failure'' panicked at ''assertion failed: result.is_err()'', /home/dhardy/other/flate2-rs/tests/gunzip.rs:19



failures:
    test_extract_failure

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

task ''<main>'' panicked at ''Some tests failed'', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libtest/lib.rs:250

Ahora para conectarlo con gdb. Hay una función conveniente para la que puede insertar un punto de interrupción, rust_panic . Una vez en gdb, break rust_panic significa que se pausará cada vez que algo desencadene un pánico, antes de hacer el desenrollamiento.

Esto es lo que una sesión podría terminar pareciendo:

$ gdb target/demo-92d91e26f6ebc557
…
Reading symbols from target/demo-92d91e26f6ebc557...done.
(gdb) break rust_panic
Breakpoint 1 at 0xccb60
(gdb) run --test test_extract_failure
Starting program: /tmp/demo/target/demo-92d91e26f6ebc557 --test test_extract_failure
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

running 1 test
[New Thread 0x7ffff6ef4700 (LWP 14254)]
[New Thread 0x7ffff5fff700 (LWP 14255)]
[Switching to Thread 0x7ffff5fff700 (LWP 14255)]

Breakpoint 1, 0x0000555555620b60 in rust_panic ()
(gdb) bt
#0  0x0000555555620b60 in rust_panic ()
#1  0x0000555555621274 in unwind::begin_unwind_inner::hb821324209c8ed246Qc ()
#2  0x000055555556bb6d in unwind::begin_unwind::h7834652822578025936 ()
#3  0x000055555556b9fd in demo::do_something () at <std macros>:8
#4  0x000055555556b98e in demo::test_extract_failure () at src/lib.rs:3
#5  0x000055555559aa4b in task::TaskBuilder::try_future::closure.8077 ()
#6  0x000055555560fd03 in task::TaskBuilder::spawn_internal::closure.30919 ()
#7  0x000055555561f672 in task::Task::spawn::closure.5759 ()
#8  0x0000555555621cac in rust_try_inner ()
#9  0x0000555555621c96 in rust_try ()
#10 0x000055555561f713 in unwind::try::ha8078a6ae9b50ccepFc ()
#11 0x000055555561f51c in task::Task::run::hdb5fabf381084abafOb ()
#12 0x000055555561f168 in task::Task::spawn::closure.5735 ()
#13 0x0000555555620595 in thread::thread_start::h4d73784c295273b3i6b ()
#14 0x00007ffff79c2314 in start_thread () from /usr/lib/libpthread.so.0
#15 0x00007ffff72e25bd in clone () from /usr/lib/libc.so.6
(gdb) 

En ese caso particular, # 0– # 2 y # 5– # 15 son ruido, # 3 y # 4 son la señal que queremos.