Code Monkey home page Code Monkey logo

bugstalker's Issues

Build fails on my Fedora 39

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 }

Async support

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

Awesome work!

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

Question: How to debug tests?

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.

debug c code

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?

async backtrace - like `backtrace` command but shows futures await-stack

Feature description

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 for
  • async 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

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

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.

TUI improvements

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

F8 - step over leads to libunwind error

single stepping with F7 works.

However using the step over function fails with following libunwind error

grafik

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.

Commands instruction?

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.

Feature: watchpoints

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.