From 857b06d984aadceaccc9f06e3b83828a911c77a9 Mon Sep 17 00:00:00 2001 From: Colin Jermain Date: Sun, 8 May 2022 10:16:25 -0400 Subject: [PATCH 1/2] Updating debugging docs with more info on rust-gdb --- guide/src/debugging.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/guide/src/debugging.md b/guide/src/debugging.md index 3a624d2d392..6f97a9d9794 100644 --- a/guide/src/debugging.md +++ b/guide/src/debugging.md @@ -32,9 +32,16 @@ Run Valgrind with `valgrind --suppressions=valgrind-python.supp ./my-command --w ## Getting a stacktrace -The best start to investigate a crash such as an segmentation fault is a backtrace. +The best start to investigate a crash such as an segmentation fault is a backtrace. You can set `RUST_BACKTRACE=1` as an environment variable to get the stack trace on a `panic!`. Alternatively you can use a debugger such as `gdb` to explore the issue. Rust provides a wrapper, `rust-gdb`, which has pretty-printers for inspecting Rust variables. Since PyO3 uses `cdylib` for Python shared objects, it does not receive the pretty-print debug hooks in `rust-gdb` ([rust-lang/rust#96365](https://github.com/rust-lang/rust/issues/96365)). * Link against a debug build of python as described in the previous chapter - * Run `gdb ` + * Run `rust-gdb ` + * Set a breakpoint (`b`) on `rust_panic` if you are investigating a `panic!` * Enter `r` to run * After the crash occurred, enter `bt` or `bt full` to print the stacktrace + + Often it is helpful to run a small piece of Python code to exercise a section of Rust. + + ``` + rust-gdb --args python -c "import my_package; my_package.sum_to_string(1, 2)" + ``` From 4720cf822379b2b14ecdbbb06b67f83641fc8c18 Mon Sep 17 00:00:00 2001 From: Colin Jermain Date: Mon, 9 May 2022 20:45:27 -0400 Subject: [PATCH 2/2] Resolving comments --- guide/src/debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/guide/src/debugging.md b/guide/src/debugging.md index 6f97a9d9794..c29930e8bf4 100644 --- a/guide/src/debugging.md +++ b/guide/src/debugging.md @@ -32,7 +32,7 @@ Run Valgrind with `valgrind --suppressions=valgrind-python.supp ./my-command --w ## Getting a stacktrace -The best start to investigate a crash such as an segmentation fault is a backtrace. You can set `RUST_BACKTRACE=1` as an environment variable to get the stack trace on a `panic!`. Alternatively you can use a debugger such as `gdb` to explore the issue. Rust provides a wrapper, `rust-gdb`, which has pretty-printers for inspecting Rust variables. Since PyO3 uses `cdylib` for Python shared objects, it does not receive the pretty-print debug hooks in `rust-gdb` ([rust-lang/rust#96365](https://github.com/rust-lang/rust/issues/96365)). +The best start to investigate a crash such as an segmentation fault is a backtrace. You can set `RUST_BACKTRACE=1` as an environment variable to get the stack trace on a `panic!`. Alternatively you can use a debugger such as `gdb` to explore the issue. Rust provides a wrapper, `rust-gdb`, which has pretty-printers for inspecting Rust variables. Since PyO3 uses `cdylib` for Python shared objects, it does not receive the pretty-print debug hooks in `rust-gdb` ([rust-lang/rust#96365](https://github.com/rust-lang/rust/issues/96365)). The mentioned issue contains a workaround for enabling pretty-printers in this case. * Link against a debug build of python as described in the previous chapter * Run `rust-gdb ` @@ -42,6 +42,6 @@ The best start to investigate a crash such as an segmentation fault is a backtra Often it is helpful to run a small piece of Python code to exercise a section of Rust. - ``` + ```console rust-gdb --args python -c "import my_package; my_package.sum_to_string(1, 2)" ```