Rust, RR, Neovim: A perfect debug combination

Rust, RR, Neovim: A perfect debug combination(github.com)

159 points by zteppenwolf 3 years ago | 97 comments

DixieDev 3 years ago |

Anyone got other useful tools for debugging within (neo)vim? Just seamlessly putting down breakpoints, stepping through code execution, and getting a fully fledged debugging UI experience (a la Visual Studio or Remedy BG)? This is possibly the only thing I miss from developing on Windows, and it's a shame!

EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.

gavinhoward 3 years ago | |

Shameless plug, but my development environment [1] may be close to what you're looking for. (There's pictures!)

A couple of details have changed since that post. The only one that you might care about is that I now have two tmux panes with gdb-dashboard. This is meant to use space better. One pane has all of the variables and nothing else. The other has everything else.

If you care about that, I'll tell you how to do it.

[1]: https://gavinhoward.com/2020/12/my-development-environment-a...

zteppenwolf 3 years ago | | |

This is very cool! I created this small convenience script without the intent to customize `Termdebug` itself, leaving any preferences to the users. But I can see many nice things you added there that can combine very well with the two!

BaculumMeumEst 3 years ago | |

The overall quality of a debugger is far more important than the question of which text editor it's integrated with for me personally.

To that end I would say Intellij products have the best debugging experience I've found on Linux. VS Code after that.

davidkunz 3 years ago | |

I use nvim-dap[1] in combination with jester[2] (by me) to run and debug Jest tests in my project, it works perfectly.

[1]: https://github.com/mfussenegger/nvim-dap

[2]: https://github.com/David-Kunz/jester

9029 3 years ago | |

I'm surprised nvim-dap-ui wasn't mentioned yet. It still has less features than vimspector, but personally I prefer the nvim-dap ecosystem. No memory viewer is a bummer though.

https://github.com/rcarriga/nvim-dap-ui

JamesonNetworks 3 years ago | |

So over the weekend I just went through a vim reworking for myself after discovering astronvim. I replaced my config with that one and installed nvim-dap-python through the user template, was able to attach and debug like I was using pycharm in a few hours of tweaking. I really like it

I did have a couple of plugins I cant really live without (ZoomWinTab and A.vim) so Im working on porting them to lua with the help of chatgpt. Really like the experience so far. Def worth checking out astronvim / nvchad

nkjnlknlk 3 years ago | | |

Finding astronvim through this comment and it looks like it may be time to move on from my regular vim to nvim. I like keeping things light so I'll probably just steal some plugins used there but the functionality looks like things I already have except with better UX. Thanks for sharing!

huseyinkeles 3 years ago | |

nvim-dap is what’s being used the most.

https://github.com/mfussenegger/nvim-dap

qbasic_forever 3 years ago | |

VS code plus its vim key binding plugin. The neovim plugin world is just way too unstable in my experience.

II2II 3 years ago | | |

Came here to say pretty much the same thing, except I use the Neovim extension for VS Code. It uses Neovim as the backend and, from my experience, behaves a lot more like (Neo)Vim. It is much easier to setup, since debugging is handled by VS Code. The main drawback is VS Code does not work in a terminal, which is okay IMHO since you still have access to Neovim from the shell.

flohofwoe 3 years ago | |

VSCode with the CodeLLDB or MS C/C++ extensions both usually work out of the box for debugging most compiled languages (so far I tried C/C++, Rust and Zig), but compared to proper Visual Studio it's very bare bones (especially the variable view panel).

delta_p_delta_x 3 years ago | | |

> compared to proper Visual Studio

Debugging in proper Visual Studio is by far the most pleasant experience I have ever had. Flame graphs, call graphs, memory and CPU utilisation graphs, straightforward call stacks and variable views... FOSS debugging utilities don't even come close to the debugging productivity on VS 2022.

ReleaseCandidat 3 years ago | |

> I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.

Totalview https://totalview.io/ or Ex-Allinea (now Nvidia) - don't know if it's still usable as a 'general' debugger though. https://developer.nvidia.com/allinea-ddt

Both don't work with Rust.

Foxboron 3 years ago | |

You could try vimspector. It's main target is vim and not neovim.

https://github.com/puremourning/vimspector/

favadi 3 years ago | |

I tried nvim-dap but it is somewhat clunky, unintuitive to use. Turn out that that using delve, gdb, pydb directly on the command line is fine, I don't really need editor integration.

salicideblock 3 years ago | |

termdebug (used by the tool linked in the topic) basically does this for anything you can debug in GDB. It's the tightest integration of debuggers and (neo)vim I have used.

There are also DAP-based integrations, which I have put the effort into using.

ilikehurdles 3 years ago | |

Look into nvim-dap and the ecosystem around it.

JestUM 3 years ago |

Investing in a good debugging tool and knowing your way around using it well, makes all the difference.

Buttons840 3 years ago | |

After recently doing some JavaScript work and not knowing how to debug it, any suggestions for a JavaScript debugger? Part of the problem is it's already difficult to get a modern JavaScript stack setup: TypeScript transpiles to JavaScript trasnpiles to different bundles that all get minified and backfilled and next thing you know your debugging a variable named i̷̪̱͆͛w̵̤̹̠͊̇̈x̷̨̻̽̍̄͆ on line 582956, and you ask your coworkers for help and none of them have ever used anything but console.log and are like ¯\_(ツ)_/¯ -- it was traumatic.

liveoneggs 3 years ago | | |

https://stackoverflow.com/questions/34087143/load-separate-s...

flohofwoe 3 years ago | | |

VSCode works well, both for command line stuff via node.js or Deno, and for (remote) browser debugging:

https://code.visualstudio.com/docs/typescript/typescript-deb...

https://code.visualstudio.com/docs/nodejs/browser-debugging

The JS-to-TS mapping is handled through source map (so you're 'debugging' the TS code, even though it's JS under the hood).

(also, in case you're not aware, browsers have a builtin debugger in their devtool panel, these also have source map support, but this may require some tinkering)

berkes 3 years ago | |

It's one of those things where 'just a puts/printf/console.log/prtln' always seems easier.

But all those tiny times add up, over years, decades. And eclipse the time of that afternoon+ spent on learning & configging debuggers in months already.

Don't be me, that senior dev who'd been promising himself for decades to really get down to learning and setting up gdbg or equivalent. And then, once invested, keeps thinking: "I should've done this years ago".

nu11ptr 3 years ago |

I personally have never used a debugger in Rust. Logging and printing has typically been enough.

For those use cases where it is tough to see the output (tests, windows services, etc.) I wrote the `rdbg` set of crates. It is essentially identical to `dbg!` and `println!` macros, but delivers messages via a TCP socket to a simple command-line viewer (which can be on the same machine or remote). The design is such that it can be enabled and used the first time within a minute or two for "quick and dirty debugging". It can just as quickly be removed or turned into a no-op with a Rust feature.

Dependency: https://crates.io/crates/rdbg

Viewer: https://crates.io/crates/rdbg-view

EDIT: Apparently I need to update the README as I added the 'msgf' and 'valsf' macros that include auto-flush which is handy for short running programs where explicit flush doesn't work due to failing program/etc.

iudqnolq 3 years ago | |

Looks handy. When you're writing certain types of programs going the opposite way can be useful.

For ex I recently added a /debug/:map_id endpoint to a server I'm writing that just returns format! ("{:#?}", state.maps.get(id)).

Obviously that'd be completely inappropriate in many cases, but for this one polling the current state via curl was quite handy.

fcoury 3 years ago |

I have written an extension for VSCode that replicates the repeat last test feature and lets you run the test under the cursor.

https://marketplace.visualstudio.com/items?itemName=fcoury.r...

thegeomaster 3 years ago |

Only if you're debugging tests.

Unfortunately using rr to debug a bigger application with lots of RAM access is not feasible.

ObscureScience 3 years ago | |

Is that true? I genuinly have no experience with it.

In their example they debug Firefox which I would consider a big application. Of course there are many levels above, and maybe you are talkning about tens of GB of memory usage?

thegeomaster 3 years ago | | |

I haven't tried with FF personally, but the issue I have is that the traces are huge and reverse execution through memory-intensive codepaths takes a very long time, making the experience really slow. Or you can run a release build (with optimizations), in which case everything gets inlined, your asserts get nuked, and you're unable to inspect state well enough to figure out what's going on. In most cases, an ordinary debugger provides a better UX for me, but for the odd memory bug untraceable by normal hardware breakpoints in a traditional forward debugger, it comes in handy.

planede 3 years ago | |

That does not mirror my experience.

colesantiago 3 years ago |

Can someone explain what I am looking at here with this? Genuine question.

capableweb 3 years ago | |

Rust - Systems programming language (although used for more than just that today)

Neovim - Text editor popular for people who like terminals (forked from vim)

RR - Debugging tool that allows you to record failures/errors and play them back, facilitating easier debugging and reproduction (simplified: basically gdb on steroids)

All together (this repository) - A editor plugin for neovim users who use Rust, to use RR directly in neovim.

baq 3 years ago |

rr is basically black magic

mijoharas 3 years ago | |

It's a real shame that it can't be made to work on arm systems

natrys 3 years ago | | |

Readme and latest release note says it now supports Neoverse N1 (ampere altra, graviton2 and maybe some cortex ones) as well as Apple M1.

icholy 3 years ago | | |

AFAIK it works on AWS graviton.

guipsp 3 years ago | | |

It does seem to work on Apple ARM

RcouF1uZ4gsC 3 years ago |

Does this setup have nice visualizations of data structures? Can it show a Vec as a list of values or a HashMap as a list of (key,value)?

zteppenwolf 3 years ago | |

Oh no, this is just a wrapper for `RR`. Any visualization customization must be done via `~/.rr_gdbinit` and `~/.gdbinit`

renox 3 years ago | |

This kind of things exist as a set of python scripts for C++.

It should be possible to do the same for Rust.

Aiedail 3 years ago |

Is there a similar tool for python? I don't like the DAP solution but prefer a gdb like python debugger :(

n8henrie 3 years ago |

I hadn't realized there were alternatives to rust-lldb for debugging rust. I have some reading to do.

sp0ck 3 years ago |

Funny thing is that thanks to rust compiler I never had a need to debug my code :-)

andsanmar 3 years ago | |

It may be true that this holds for issues related with out-of-bounds accesses or temporal safety errors, but nothing eludes your application to contain logic bugs. In fact, whenever the application is big enough and you spot a logic error, the debugging burden is still there. Good part is that the debugging utilities for C/C++ are still helpful for Rust programs.

pyrale 3 years ago | | |

Usually, understanding the type system changes you code/thinking about business logic too. That stems from the habit of thinking about how to check your expected behaviour before implementing it.

Needing a debugger still happens once in a while, but languages/projects that are well adapted to this way of thinking really make it extremely uncommon.

carlmr 3 years ago | |

So true. With proper type driven design you basically don't need a debugger anymore.

But I still find it helpful when you need to check what's wrong in other people's code, since they might not design with types like I do.

galangalalgol 3 years ago | | |

I find myself using the debugger to explore complex types created by procedural macros. You can use cargo to expand them andnpoke around, or dump the structure to debug if it derives it, but sometimes the debugger seems easier.

Also it can help find why something three crates deep into your dependency tree panicked.

yakubin 3 years ago | |

Debuggers aren’t only for debugging. They’re also for exploring an unfamiliar codebase, speeding up the process of familiarising oneself with it.

favadi 3 years ago |

rr is pure magic! I wish that it is available on macOS.

wuming2 3 years ago | |

Isn’t Apple known for integrating DTrace in Leopard back in 2007?