Using gdb with tmux/gdb-dashboard

[ThatGeoGuy]

I have a bit of an odd question about how to use nextest with a debugger.

I usually like to debug using gdb-dashboard, and in particular I use a variant of the multiple terminal support that's in their wiki with Rust. This (located in my .bashrc) is effectively:

rust-gdb-tmux() {
    local id="$(tmux split-pane -hPF "#D" "tail -f /dev/null")"
    tmux last-pane
    local tty="$(tmux display-message -p -t "$id" '#{pane_tty}')"
    rust-gdb -ex "dashboard -output $tty" "$@"
    tmux kill-pane -t "$id"
}

This is mostly great, and does what you would expect (opens the dashboard on a new vertical pane, and allows for gdb commands in the existing pane). What I want to do is effectively something like:

cargo nextest run --debugger "rust-gdb --args" my_test

As outlined in the docs. This seemed to work on its own, so I opted to extend this with my above rust-gdb-tmux script. What I tried to do was just a simple:

cargo nextest run --debugger "rust-gdb-tmux --args" my_test

But this seems to fail. I'm not entirely sure what has gone wrong here, but it would be nice to be able to use nextest to launch this properly. Is there some small fix I can make here, or is this something that isn't supported?

What I get is something akin to:

info: executing debugger command: rust-gdb-tmux /home/jeremy/Code/my-crate/target/debug/deps/my-crate-16765c49383c6029 --exact my-test --nocapture
       XFAIL [   0.000s] (1/1) my-crate my-test
  execfail ─
    error spawning child process
      caused by:
      - No such file or directory (os error 2)

  Cancelling due to test failure:
────────────
     Summary [   0.000s] 1 test run: 0 passed, 1 exec failed, 59 skipped
       XFAIL [   0.000s] (1/1) my-crate my-test
error: test run failed

Taking this a step farther, I tried to run that command directly, since it lists that "executing debugger command" in the log:

$ rust-gdb-tmux --args /home/jeremy/Code/my-crate/target/debug/deps/my-crate-16765c49383c6029 --exact my-test --nocapture

and _it just works_™, which is more confusing. 🤔 It seems that there's some problem with how the "child process" (which is really a couple of processes given my bash function) is launched here, and I'm not entirely sure if this is a user error or a software error.

Any thoughts of what to try here?

[pratikrath126]

Hey! The issue is that nextest runs the debugger via , not through a shell, so your bash function isn't found. Functions/aliases only exist in interactive shells.

Fix: turn the function into an executable script and put it somewhere in your PATH, e.g.:

1. Create :

Make it executable: .

2. Use it with nextest:

or if it's not on PATH, give the full path.

Alternatively, you can use but the script approach is cleaner.

That should let nextest spawn the debugger correctly. Hope that helps!

[pratikrath126]

Hey! The issue is that nextest runs the debugger via Command::new, not through a shell, so your bash function rust-gdb-tmux isnt found. Functions and aliases only exist in interactive shells.

Fix: convert the function to an executable script and place it in your PATH. For example:

1. Create ~/bin/rust-gdb-tmux:

#!/usr/bin/env bash
id="$(tmux split-pane -hPF "#D" "tail -f /dev/null")"
tmux last-pane
tty="$(tmux display-message -p -t "$id" "#{pane_tty}")"
exec rust-gdb -ex "dashboard -output $tty" "$@"

Make it executable: chmod +x ~/bin/rust-gdb-tmux

2. Use it with nextest:

cargo nextest run --debugger "rust-gdb-tmux" my_test

Or provide the full path if not on PATH.

Alternatively, you could use:

cargo nextest run --debugger "bash -c \"rust-gdb-tmux --args\"" my_test

but the script approach is cleaner.

This should allow nextest to spawn the debugger correctly. Hope that helps!

[ThatGeoGuy]

oof, hit by the ol' bash function vs. script.

Thanks! This got me going.