[HN Gopher] Visualize and debug Rust programs with a new lens
___________________________________________________________________
Visualize and debug Rust programs with a new lens
Author : alex_hirner
Score : 207 points
Date : 2025-05-25 08:33 UTC (4 days ago)
(HTM) web link (firedbg.sea-ql.org)
(TXT) w3m dump (firedbg.sea-ql.org)
| waschl wrote:
| That looks very impressive! Would give it a spin but as far as I
| can tell I can't use it with my Rust os kernel running inside
| qemu
| Veserv wrote:
| This is just a trace viewer. Except the trace visualization is
| vastly less dense than any standard trace viewer and seems to
| provide no meaningful execution time information.
|
| Compare to chrome://tracing
|
| https://www.chromium.org/developers/how-tos/trace-event-prof...
|
| I am not sure if trace visualizers were invented 20 years ago for
| the original time travel debuggers, but they have certainly been
| used for time travel debugging visualization since at least 20
| years ago.
| sureglymop wrote:
| It's definitely a little more than just a trace viewer.
|
| As the page reads, it is a time traveling debugger. You can
| jump back and forth between different snapshots of time during
| the execution of your program. It's neat because for compiled
| languages like rust doing something like this is more advanced.
| Veserv wrote:
| That is exactly how trace viewers have been used with time
| travel debuggers for literally, and I do mean literally, over
| 20 years.
|
| You click a point in the trace, you jump to that point in
| time. That has been the standard integration for decades.
| sureglymop wrote:
| I was under the impression that with a trace viewer you
| would do that after the execution of the program has
| finished. Learned something!
| quotemstr wrote:
| It's both. It is a trace viewer, but they instrument native
| code to emit logs of its operation, e.g. calls and returns,
| similar to what the recent non-performance-counter rr branch
| does. Except for some reason it's coupled to a specific GUI
| and a specific language instead of being a general purpose
| tool like RR is.
|
| The tech industry is getting stupider and hype-ier as it
| implodes.
| Rust-Trends wrote:
| Nice project! I'll be highlighting it in the next edition of the
| https://Rust-Trends.com newsletter.
| spencerflem wrote:
| Cool, reminds me somewhat of Glamorous Toolkit [1], another
| project I just found out about. Excited to give it a try, I love
| these sort of "explain a program as it's running" type tools.
|
| 1. https://gtoolkit.com/
| levkk wrote:
| I want to use this right now, but two issues:
|
| - Bash script from Internet requiring sudo, no way
|
| - VSCode plugin? I don't use VSCode. I'm not switching from Zed
| (literally built in Rust for Rust development)
|
| Help me out, what can I do to try this?
| mdaniel wrote:
| Depending on where your "Internet" boundary starts, you can
| clone the repo and run its install.sh although I think it's for
| _really lazy_ people since it just downloads the GitHub release
| artifact anyway
| https://github.com/SeaQL/FireDBG.for.Rust/blob/1.81.0/instal...
|
| I don't see that VSCode is required, they have a section
| dedicated to CLI usage
| https://github.com/SeaQL/FireDBG.for.Rust#firedbg-command-li...
| and even the "firedbg open" seems to just be a convenience
| method for file globbing
| https://github.com/SeaQL/FireDBG.for.Rust/blob/1.81.0/comman...
|
| I'm a little with you that it is sus that they don't seem to
| have any .ts nor package.json file in that repo which would
| allow one to (a) see what the extension does (b) build the
| .vsix themselves
| leoh wrote:
| They're just trying to offer an easy way to try things out and
| unsafe code from Firefox would be insanely harmful for their
| brand. Of course, if you take a moment to merely download the
| bash script and inspect it. It's truly not dissimilar from
| downloading a repository from GitHub and building it. In
| general, certainly, yes, you don't want to run arbitrary
| programs.
| orsenthil wrote:
| This is very good. Excellent user-interface too. Reminded me of
| Pythontutor that I use.
| dochtman wrote:
| Does this work on macOS?
|
| On mobile (Firefox on iOS) why does this site keep putting
| animations in my face?
| mdaniel wrote:
| Their install.sh specifically mentions Darwin
| https://github.com/SeaQL/FireDBG.for.Rust/blob/1.81.0/instal...
| and they ship pre-compiled for both aarch64 and x86_64
| https://github.com/SeaQL/FireDBG.for.Rust/releases/1.81.0
| quotemstr wrote:
| From a debugger's point of view, Rust is just another native code
| language. DWARF tells you how to get stacks, find variables, and
| interpret chunks of memory as data structures. Anyone trying to
| pitch you a debugger specifically for Rust is trying to ride a
| hype wave or just plain bamboozle you.
| mdaniel wrote:
| relevant: _DWARF as a Shared Reverse Engineering Format_ -
| https://news.ycombinator.com/item?id=44113026 - May, 2025 (17
| comments)
| khuey wrote:
| It appears to rely on source instrumentation so it really is
| language specific.
| quotemstr wrote:
| Oh. When I read the section on instrumenting function
| returns, I thought they were going for something more
| general, since they talk about analyzing assembly. Now I see
| they're looking at individual Box and Rc instances and have
| special cases for stdlib data structures. Async support is
| also a to-do item.
|
| I can't see this approach working for very long. Tracing at
| the binary level, whether you do it as RR does with
| performance counting or whether you do it via instrumentation
| like Undo and iDNA, works for the general case because it
| records execution at the lowest level available to a process
| and therefore captures everything, without special cases.
|
| If these guys want to make a fancy time travel debugger data
| explorer, that's great. They could in principle make one on
| top of existing tracing technology without having to
| simultaneously reinvent both the debugger core and the GUI.
| khuey wrote:
| From https://firedbg.sea-
| ql.org/blog/2023-12-11-architecture-of-f... it seems more
| like lldb automation than what "time travel debugger"
| brings to mind.
| Veserv wrote:
| Wow. It is not even a proper time travel debugger. I just
| assumed they were ingesting a proper time travel debugger
| log and driving a proper replay engine and just wrote a
| bad integrated trace viewer on top. That would at least
| be excusable. This is just inane.
|
| The "time travel debugger" solution they use
| automatically sets numerous breakpoints and then records
| a tiny, useless fraction of the information needed to
| actually recreate past state, but is almost certainly
| slower than any actual, fully-functional time travel
| debugger by multiple orders of magnitude. That was the
| same technique used by the built-in gdb "reverse
| debugging" which, at least historically, resulted in
| 1,000x-10,000x (yes, really) slowdown compared to modern
| techniques which are on the order of 2x-10x. And to at
| least give gdb some credit, gdb reverse debugging was at
| least a complete time travel debugger since it recorded
| everything; it was just unusably slow. That is more than
| can be said about whatever this is. They would be
| significantly better off in both functionality and
| performance wrapping literally any other actual time
| travel debugger solution.
|
| Then we add on their awful, bespoke trace viewer. I
| originally just chalked it up to them being unaware of
| standard practices since most people are unfamiliar with
| time travel debugging and the associated tooling and they
| just wanted to show off what they did with some bluster.
| That is excusable, if somewhat unfortunate. But this is
| the metaphorical equivalent of claiming you have solved
| the problem of inserting screws because you invented the
| hammer which is much better at hammering in screws than a
| brick.
|
| Their marketing statements are unacceptable
| misrepresentations of their capabilities with respect to
| commonly-accepted meanings.
|
| It is utterly baffling that this is more popular than the
| recent UndoDB thread [1]. They have a real time travel
| debugger and have been doing it for like 15-20 years.
| They are actual veterans doing quality engineering.
|
| [1] https://news.ycombinator.com/item?id=44076300
| quotemstr wrote:
| That's the culture that's emerged in tech over the past
| few years: a rejection of technical rigor and an abuse of
| language to ape, poorly, the cachet of past
| accomplishments. This thing is a "time travel debugger"
| (it isn't). A program to bundle typescript into an
| executable is called a "compiler". They use cool-sounding
| words without the substance.
| yencabulator wrote:
| Where do you see source instrumentation? I see Rust-specific
| details so for sure it's language-specific, but I didn't see
| any mention of altering the source code.
| khuey wrote:
| I didn't look at it very closely but it seems like you need
| to add fire::dbg! macros to your code if you want anything
| beyond function parameters/return values.
| yencabulator wrote:
| Oh so it can't stop at a breakpoint and inspect local
| variables? Weeird.
|
| Is it like just a trace viewer fed data by debugger-style
| mechanisms?
| khuey wrote:
| Seems like it drives lldb with automation and fills up a
| database with a dynamic call graph and the data that
| crosses function call boundaries.
|
| https://firedbg.sea-ql.org/blog/2023-12-11-architecture-
| of-f...
| RealityVoid wrote:
| Sure, I agree, but in my experience, probe-rs for example has
| much better ability to step and identifies the variables much
| better than GDB did. Not sure if it's how it handles the name
| mangling or what, but GDB couldn't interpret a lot of context.
| vvern wrote:
| While that's sort of true, there's a lot of language specific
| things that go into making the UX of a debugger pleasant (think
| container abstractions, coroutines, vtables and interfaces).
| Specifically async rust and Tokio gets pretty interesting for a
| debugger to deal with.
|
| Also, there's usually some language (and compiler) specific
| garbage that makes the dwarf hard to use and requires special
| treatment.
| lpapez wrote:
| This is true in the same way that Dropbox is just a wrapper
| around rsync.
| tonyhart7 wrote:
| would love to do this with database instead, inspect query and so
| on
|
| anyone know the tool name??? I know it exist but forget it while
| ago
| hencoappel wrote:
| Something like the SQL Server Management Studio execution plan
| view?
|
| https://learn.microsoft.com/en-us/sql/relational-databases/p...
| artogahr wrote:
| Dequery might be what you're looking for: https://dequery.io
| forrestthewoods wrote:
| Please show me this being used to debug a real program. Toy
| examples that don't do any real work isn't interesting. My
| confidence that this work for an actual program is approximately
| zero percent.
| leoh wrote:
| Let's stay positive here. This is very cool.
| Veserv wrote:
| When it is objectively not a time travel debugger as
| prominently advertised, let us not stay mindlessly positive.
| leoh wrote:
| "Simple things should be simple. Complex things should be
| possible." - Alan Kay
|
| Rust really embodies this imo. I think it will be a few more
| years, but we're going to be seeing a lot more Rust -- and for
| good reason.
___________________________________________________________________
(page generated 2025-05-29 23:01 UTC)