godzie44 / bugstalker Goto Github PK

Now BugStalker can provide a some of new features for support async debuging.

Problem

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.

What to do

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.

Runtimes support

Currently we only declare support for tokio runtime.

Sub issues

• tokio oracle - like tokio console
• #27
• async step - like regular steps, but step in selected future
• async var locals - like var locals but for future captured data
• ...

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.

Add watchpoints (data breakpoint) for memory regions, variables and arguments

As a first step to integrate with third-party code editors, need to implement
https://github.com/microsoft/debug-adapter-protocol

Add ability to reconfigure key map at TUI mode.

Feature description

Create async backtrace command. This command print all futures that is parked at an await point, by decomposing what, exactly, it’s waiting for.

Example:
TODO

Implementation notes

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).

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:

1. Set breakpoints in task constructors/destructors and store task information at these points

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.

2. Set breakpoints at tokio runtime initialization process and save pointers task queues

This 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?".

3. Move down the call stack at every async backtrace command and find pointers into task queues

When 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.

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 }

There much more improvements that can be maded for TUI mode:

• Resize tabs (the ability to expand interested window)
• Better tab switching
• active line must glued to the middle of render area (thanks @jan-ferdinand)
• colorize data in variables tab

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.

Set breakpoint at memory address from TUI leads to panic