Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What a good debugger can do

werat.dev

Post reply on HN
Print view View original

51–60 of 208 posts

Re: What a good debugger can do

#51

Post by matsemann »

nijave wrote: post #31
sebastianconcpt wrote: post #12

a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, can pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point in history, and can even record the entire pro…

>can step through the code backward and rewind the program state to any point in history This seems impossible for anything that modifies external state. Say 1. Open database connection 2. Commit data 3. Close database connection How would you rewind right before #2 if you've already completed step #3? You'd need the socket/connection you already closed Unless that means something more like "keep a running record of…

Yeah it's not perfect, but it often works well enough. Just another benefit of isolating code into stateless stuff.

One use case I have is for instance debugging a bug that's hard to trigger. When it finally happens and my breakpoint is hit, I can edit the code, hot swap it live, drop the current frame and then make it call my updated function again as if the original call never happened.

Re: What a good debugger can do

#52

Post by RcouF1uZ4gsC »

I have mostly found the people who dismissed debuggers tended to be more Unix/Linux people, probably because raw gdb is such a huge pain to use. Windows developers and Visual Studio developers where the debugging experience is so easy, tend to sing the praises of debuggers. I wonder if it a bit of sour grape for the Unix/Linux crowd?

Re: What a good debugger can do

#53

Post by igouy »

aidenn0 wrote: post #29
sebastianconcpt wrote: post #12

a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, can pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point in history, and can even record the entire pro…

Is there a ST implementation with a time-traveling debugger? That's probably the one feature I miss when using sbcl/slime.

Depends what functionality you think "a time-traveling debugger" must provide, Smalltalk implementations usually provide something like this:

https://cuis-smalltalk.github.io/TheCuisBook/The-Debugger.ht...

Re: What a good debugger can do

#54

Post by matheusmoreira »

sokoloff wrote: post #4
choletentent wrote: post #2

This piece from Linus on why he doesn't like debuggers resonates with me [1], although I confess I use Python pdb quite often. [1] https://lkml.org/lkml/2000/9/6/65

I really enjoyed this thought in that mail: “Tough. There are two kinds of reactions to that [time lost from a bug you introduced in kernel dev]: you start being careful, or you start whining about a kernel debugger.”

He also reminds people why everyone pulls from torvalds/linux to this day:

> People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system.

Re: What a good debugger can do

#55

Post by matheusmoreira »

I found GDB to have a steep learning curve, even stepping through code was hard at first. Now I simply cannot work without it anymore. I have GDB scripts for visualizing all my data structures now. GDB script is a painful little language but it just changed everything for me.

Re: What a good debugger can do

#56

Post by akkartik »

aidenn0 wrote: post #44
akkartik wrote: post #36

Earlier quoted context omitted.

I'm very happy to hear it! Can you point me at a few of them?

Mentioned in TFA is "rr"; it serves up to gdb the history of the program and you can use tracepoints (also mentioned in TFA) to essentially retroactively add prints. Gdb is ... not particularly ergonomic, but it is eminently scriptable and writing programs to generate arbitrary logs post-facto is a useful skill. Undo is another one for Linux programs, and I think I've seen developers from them post here.

The big problem with debuggers in my experience is the difficulty of setup. They take a lot of code to build, and if you use a slightly different language or compiler or OS you're SoL. Or at least facing some rabbitholes of unknown depth.

The most sophisticated debuggers seem to target C or Lisp. But lately I don't use either.

I've never gotten time-travel debugging in gdb to work. And it's been out for more than 10 years at this point. The last time was 2 years ago, so I forget the details. I do love tracepoints in gdb.

I've been watching https://rr-project.org for a while. The instructions still say, "build from source".

I looked at LLDB after your previous comment. Got it installed, but I can't actually get it to set a breakpoint on Linux. The docs seem optimized for Mac.

I have no doubt that once you get something set up just right you can do great things with it. But the power to weight ratio seems totally out of whack. Part of the goal of my projects recently has been to show that you can get a bunch of features far more simply if you build on a base of logging. If the programmer is willing to modify the program, a single tool can help debug programs in a wide variety of languages. They just have to follow a common and fairly simple protocol.

The big drawback of my approaches is that they don't scale for long runs of huge codebases. That hasn't been an issue for most programs I ever want to debug. Why should I pay the complexity costs of debugging gcc or Firefox for small programs.

Re: What a good debugger can do

#57

Post by AcerbicZero »

Honestly if most debuggers did what the author suggests in the first paragraph, I'd use them 10x more. Other than Pry for ruby I've not found many to debugger tools that let me drop into code, run parts of it, examine variables etc, without needing a 4 year degree in using the debugger itself.

Re: What a good debugger can do

#58

Post by BiteCode_dev »

AcerbicZero wrote: post #57

Honestly if most debuggers did what the author suggests in the first paragraph, I'd use them 10x more. Other than Pry for ruby I've not found many to debugger tools that let me drop into code, run parts of it, examine variables etc, without needing a 4 year degree in using the debugger itself.

Pdb comes to mind.

Re: What a good debugger can do

#59

Post by hobs »

AcerbicZero wrote: post #57

Honestly if most debuggers did what the author suggests in the first paragraph, I'd use them 10x more. Other than Pry for ruby I've not found many to debugger tools that let me drop into code, run parts of it, examine variables etc, without needing a 4 year degree in using the debugger itself.

Pycharm/Intellij stuff does everything you mention in a fairly simple GUI that doesn't make you understand how to set conditional variables, but encourages you to realize you want to
Post reply on HN