godzie44 / bugstalker Goto Github PK
View Code? Open in Web Editor NEWRust debugger for Linux x86-64
License: MIT License
Rust debugger for Linux x86-64
License: MIT License
I tried running the project with
cargo run
Unfortunately it fails with the following build error
--- stderr
thread 'main' panicked at /home/phil/.cargo/registry/src/index.crates.io-6f17d22bba15001f/unwind-sys-0.1.3/build.rs:16:55:
called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I figured that this is due to my libunwind version which is 1.7-rc1
. The build.rs of unwind-sys
wasn't prepared to deal with release candidates. It got fixed with following commit
The issue can be solved by updating unwind
crate
-unwind = { version = "0.4.1", features = ["ptrace"], optional = true }
+unwind = { version = "0.4.2", features = ["ptrace"], optional = true }
Add ability to reconfigure key map at TUI mode.
Now BugStalker can provide a some of new features for support async debuging.
Debug of async program in rust very hard for a lot of reason. Compiler dont generate good DWARF for async programs, and debugger dont know nothing about futures, about state machine generated by compiler and other tricks of rust async code.
We can create a some tools for work with async code. It may be just information tools (like tokio oracle) and some asynchronous analogues of regular commands. Asynchronous analogues - is a regular commands (like step
, or backtrace
) but prefixed with async.
Currently we only declare support for tokio
runtime.
var locals
but for future captured dataHey, just wanted to say that the latest version is missing the v
prefix: https://github.com/godzie44/BugStalker/releases/tag/0.2.1
Whereas the previous versions had it, e.g. https://github.com/godzie44/BugStalker/releases/tag/v0.2.0
It is probably best to push v0.2.1
without deleting 0.2.1
in case someone packaged it already π»
Set breakpoint at memory address from TUI leads to panic
Hi! I just tried the debugger out and damn it's pretty neat! Just wanted to say that I like this project :) Keep it up c(^-^)c
Hi! May I ask how I can debug a test? Would be cool if you could debug a test with bs mod1::mod2::mod3::name_of_test_function
.
EDIT1: Ok, they are stored in target/debug/deps
but... I can't find my integration tests there.
Hi! I've got a little question regarding debugging c with bugstalker instead of gdb.
Assuming we've got the following file:
/tmp/main.c
#include <stdio.h>
int main() {
puts("Hello there!");
return 0;
}
and if I execute the following commands:
cd /tmp
gcc main.c
bs a.out
now if I do b main
I'm getting:
Add deferred breakpoint for future shared library load?
is that expected? Do you have an suggestion how to fix this so that I can debug c code?
As a first step to integrate with third-party code editors, need to implement
https://github.com/microsoft/debug-adapter-protocol
Currently there is field
operator in data query expressions (DQE) that supose to get element from hashmaps by string key. Index operator dont supported in maps and sets at all, and will be great to fix it.
Create async backtrace
and async backtrace all
command.
async backtrace
- print all futures of currently executed async tasks (current executed tasks count <= async workers count), by decomposing what, exactly, itβs waiting forasync backtrace all
- print all async workers state (all workers with all tasks with full future stack)Example (async backtrace
):
Async worker #2 (pid: 388235)
Current task: 3
#0 async fn tokioticker2::new_ticker_task
suspended at await point 0
#1 async fn tokioticker2::new_ticker_task_inner1
just created
Async worker #3 (pid: 388236)
Current task: 7
#0 async fn tokioticker2::new_ticker_task
suspended at await point 0
#1 async fn tokioticker2::new_ticker_task_inner1
suspended at await point 0
#2 future tokio::time::sleep::Sleep
Currently we will focus on tokio
async runtime.
"Root" of our batcktrace is a tokio
tasks. Any suspended task must wait some future, that future wait another and so on. The place where we can find root futures (tasks) is the local queues (TODO may be not only local queues, need rnd) of each worker (worker is a system thread). Place where we can find current task - is a frame where run_task
function executed.
Unfortunately Tokyo does not provide some sort of explicit metadata exposed for debuggers. So there is no easy way to get tasks-queues addresses in memory. Lets describe possible solutions:
This solution good for tokio oracle, because give us "real-time" information. Visualization of this information we can use in tui interface, and it's pretty good. But this solution give us a big overhead - we stop whole program when task created or drop'd.
tokio
runtime initialization process and save pointers task queuesThis solution is better then previous one cause we set breakpoint only once, so overhead is minimal. But what if debugee program not using a tokio runtime? What should be the reaction to an error when setting a breakpoint? It looks like we need to check some characters before starting the program to answer the question - "is tokio
runtime used?".
async backtrace
command and find pointers into task queuesWhen user enter async backtrace
command we can to move down the call stack until the worker loop acting as the scheduler is reached (currently this is a worker::Context::run
function). Then we can observe local queue of the worker. Then we do the same for all threads. Point to locals queues can be cached.
It looks like we should stick with solution number 3; it allows us to perform computations only in response to a
async backtrace
command and does not have any additional overhead.
There much more improvements that can be maded for TUI mode:
single stepping with F7 works.
However using the step over
function fails with following libunwind error
I reproduced this behaviour with the current HEAD revision. In order to be able to build I had to update the unwind
crate. See my other issue #1.
While I haven't tried BugStalker yet (just discovered it) I have noticed the absence of one gdb command that would probably be quite easy to implement and has proved useful in gdb in the past for me.
That is the commands
instruction which simply sets a list of commands to be executed automatically when a breakpoint is hit. This can be useful to e.g. print all the backtraces for a given breakpoint or some specific pieces of data at every occurence relatively quickly.
Add watchpoints (data breakpoint) for memory regions, variables and arguments
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.