Compatibility with color-backtrace in 0.1.3 #828
Comments
|
Thanks for reporting! According to your stacktrace, it happens in this line: gdext/godot-core/src/private.rs Line 361 in 15bc053 So the Worst case we could just print "no panic info" instead of |
|
Besides, my previous tests triggered a panic in the Such panic cannot be caught by the debugger either, which is terrible for debugging. |
|
It seems that gdext/godot-core/src/private.rs Line 333 in 15bc053 This hook is taken when runing gdext/godot-core/src/private.rs Line 344 in 15bc053 I didn't see this |
|
I hope to get a pretty backtrace (from color-backtrace, printed to stdout) during debugging.
But when released, I just need to collect plain backtrace as crash logs. I take the following code from gdnative. It somehow works well in 0.1.1 (or earlier?), and I can see the crash from godot logs. fn init_panic_hook() {
let old_hook = std::panic::take_hook();
std::panic::set_hook(Box::new(move |panic_info| {
let loc_string;
if let Some(location) = panic_info.location() {
loc_string = format!("file '{}' at line {}", location.file(), location.line());
} else {
loc_string = "unknown location".to_owned()
}
let error_message;
if let Some(s) = panic_info.payload().downcast_ref::<&str>() {
error_message = format!("[RUST] {loc_string}: panic occurred: {s:?}");
} else if let Some(s) = panic_info.payload().downcast_ref::<String>() {
error_message = format!("[RUST] {loc_string}: panic occurred: {s:?}");
} else {
error_message = format!("[RUST] {loc_string}: unknown panic occurred");
}
godot_error!("{}", error_message);
if let Ok(str) = format_backtrace_string() {
godot_print!("{str}");
}
(*(old_hook.as_ref()))(panic_info);
}));
}
fn format_backtrace_string() -> Result<String, std::io::Error> {
use backtrace::Backtrace;
use color_backtrace::{termcolor::NoColor, BacktracePrinter};
let mut out = NoColor::new(vec![]);
BacktracePrinter::new().print_trace(&Backtrace::new(), &mut out)?;
Ok(String::from_utf8(out.into_inner()).unwrap())
} |
This probably falls under #411. Fully agree that we should look for ways to trigger the debugger.
Hm, independently of this issue in gdext, do you think that's something worth reporting to
Good question, do you think this should be unified somehow?
The main takeaway here seems to be calling the previous hook, right? Btw, you seem to have quite a concrete idea how to improve panic handling. Would you be interested in helping out with a pull request? 🙂 |
|
@Bromeon I'm glad to offer some help, but sorry I don't have much experience with Rust (especially runtime) and I'm not familiar with foundations of gdext yet... |
|
Let us know if we can help somehow. Our Discord community is also quite friendly in case you need some onboarding 🙂 If not, that's also fair, just keep in mind that I'm currently addressing many foundational parts for v0.2, and likely won't get around looking into very specific integrations (like color-backtrace or #832) for several months 😉 |
|
Oh, I further noticed that my color-backtrace is unexpectedly stripped sometime. In a panic triggered by a custom callable (used to connect to a So the only |
|
@QuadnucYard note that in the meantime, we disabled panic hooks in Release mode (#889). So it might be that Release mode already has the issue solved. Other than that, do you plan to investigate this? I don't see any concrete actionables on gdext side, as it's not even clear whether it's color-backtrace or gdext misbehaving. If not, I would probably close this. |
I just run this code:
It will print unexpected panic information after normal information.
It seems alright in 0.1.1 with the output below, despite an issue with
unwind:But on more unexpected stack backtrace from panic (
no panic info available) occurs in 0.1.2 and 0.1.3 as belowIf I do not use color_backtrace, only a simple piece of information is given (v0.1.3).
And no backtrace is printed.
Rust version:
rustc 1.82.0-nightly (7120fdac7 2024-07-25).color-backtrace=0.6.1Run with
RUST_BACKTRACE=full.So is this a bug, or does it require additional setting up panic handling? Thank you for your response!
The text was updated successfully, but these errors were encountered: