Comments (5)
As an experiment I implemented first std::panic::catch_unwind
and then std::thread::spawn
in probe_rs::cmd::dap_server
, and they both behave pretty much the same. It protects the debugger from exiting on a panic, but the information available to the end user isn't very useful. See the following code snippet, as well as the documented TODO
for why this was abandoned.
pub fn run(cmd: Cmd, time_offset: UtcOffset) -> Result<()> {
let log_info_message = setup_logging(time_offset)?;
// The debug server runs as a background process that the VSCode extension depends on.
// If the server panics, the VSCode extension will not be able to communicate with it,
// and the user will have no idea what happened.
// The debug server and associated code relies on standard Rust error handling, and will
// report `Err` values to the user, in appropriately formatted messages.
// However, the various crates used by the debug server may panic, so we catch those panics
// here, and report them to the user via the logging mechanism, which is configured in `setup_logging`,
// to ensure the VSCode extension can pick up the error and report it to the user.
match thread::Builder::new()
.name("probe-rs DAP server".to_string())
.spawn(move || debug(cmd.port, cmd.vscode, &log_info_message, time_offset))
{
Ok(dap_server_handle) => {
if let Err(err) = dap_server_handle.join() {
tracing::error!(
"Debug server thread panicked. Please report this as a bug: {err:?}"
);
// TODO: The value reported for `err` is not very helpful, because it is a `Box<dyn Any + Send + 'static>`.
// [This RFC](https://github.com/rust-lang/rust/issues/96024) when it has run its course,
// we can something like the proposed `err.request_value()` on the backtrace.
}
}
Err(e) => {
tracing::error!("Failed to spawn probe-rs DAP server thread: {e:?}");
}
};
Ok(())
}
Coincidentally, the work that was done in probe-rs/vscode#63 and #1699, effectively means that Rust's panic message and stack trace, will be displayed to the user. In other words, this opens up the possibility to allow the use of panic!
, expect!
, todo!
etc. in the API, and still provides an acceptable user experience.
Based on that, I will close this issue as completed.
from probe-rs.
I think I would still implement this because it lets you shutdown gracefully instead of crashing the DAP server :)
from probe-rs.
The code posted above is done and tested and can be implemented. However, the current version of Rust obscures the original panic message and stack trace. Until this RFC completes, the current experience is still better (more informative for the user). We can keep this issue open until then :)
from probe-rs.
Uhm, I am pretty sure it should be possible to log the panic :)
from probe-rs.
It is currently being logged, but as soon as you hide it behind a spawn
or a catch_unwind
, it is lost. I imagine that is why the RFC is there. If I'm mistaken, I'd love you to show me the way :)
from probe-rs.
Related Issues (20)
- [Request] Make the RegisterDataType enum public HOT 1
- Linking with `cc` failed error while trying to install HOT 3
- cargo embed RTT invalid chars and incomplete output HOT 2
- Renamed `STM32G471RE` to `STM32G491RE`? HOT 1
- Add support for Texas Instruments CC13xx/CC26xx devices HOT 2
- STM32F103 - Cargo flash problem HOT 2
- cargo-flash documentation references `cargo flash --list-chips` HOT 1
- Support for Linux GPIO subsystem based bit-bang driver on the single board computers (like the Raspberry Pi and the BeagleBoards)
- Tracking Issue: `src/debug` adding functionality and refactoring as required - will require multiple PR's
- RTT/defmt broken since #1738 HOT 2
- broken release links HOT 2
- Supporting CMSIS-DAP DAP_PACKET_COUNT to enhance speed. HOT 6
- UF2 Support HOT 3
- Incorrect reset behaviour HOT 6
- Broken arguments HOT 1
- Parse JTAG scan chain from CMSIS-SDF file HOT 4
- Add support for STM32U595/5A5 HOT 4
- Unable to use probe-rs with an fe310g002 microcontroller HOT 7
- Call jtag_scan even when it is provided through chain settings HOT 1
- Cannot connect to LPC55S69 chip HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from probe-rs.