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

81–90 of 208 posts

Re: What a good debugger can do

#81

Post by layer8 »

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…

Only the program state gets rewound, not anything external to the process (or whatever is hosting the program). Just like hitting a breakpoint only pauses the program, not the external world.

Re: What a good debugger can do

#82

Post by zwieback »

hnthrowaway0315 wrote: post #67
zwieback wrote: post #48

I'm a debugger lover and Visual Studio's is pretty great but GDB is also awesome. However, when debugging embedded systems with a good trace probe it's another whole world, using on-chip trace capabilities and being able to break on things like register or peripheral access makes it even more exciting. And expensive, unfortunately, since it's such a niche thing.

Just curious how does one build the tools you talked about? I'm referencing both hw and sw: hw part I guess is "on chip trace capabilities" and sw is "break on registers or peripheral access". I'm not an embedded dev neither am I a debugger developer but I'm playing with toy OS dev so just curious.

The setup I'm most familiar with is ARM-based microcontrollers, here's an overview from their docs: https://developer.arm.com/documentation/ihi0014/q/Introducti...

and the debugger from Keil (used to be independent, now part of ARM): https://www2.keil.com/mdk5/debug

Re: What a good debugger can do

#83

Post by msoad »

Unfortunately debug-ability usually stops when you have a distributed system in which each part of the system is playing a different song. I wish my job was working on a program that I could run on a single machine. Then I'll look into debuggers. For now I'm `print`ing and hopelessly looking into service logs in DataDog :(

Re: What a good debugger can do

#84

Post by aflag »

Jorengarenar wrote: post #47

>When people say “debuggers are useless and using logging and unit-tests is much better,” Who? Who does say that? Freshman students who barely started coding? >I suspect many of them think that debuggers can only put breakpoints on certain lines, step-step-step through the code, and check variable values. That alone provides enough value to know debuggers are useful.

Linus Torvalds famously dislike them: https://lwn.net/2000/0914/a/lt-debugger.php3

Re: What a good debugger can do

#85

Post by layer8 »

msoad wrote: post #83

Unfortunately debug-ability usually stops when you have a distributed system in which each part of the system is playing a different song. I wish my job was working on a program that I could run on a single machine. Then I'll look into debuggers. For now I'm `print`ing and hopelessly looking into service logs in DataDog :(

It’s a good reason to not unnecessarily distribute your system.

Re: What a good debugger can do

#86

Post by xkriva11 »

I'm missing a few other items on this list that I use daily in Pharo

- being able to open the debugger directly from the program. What the "debugger" command does in JavaScript. Conditional breakpoints are easier to work with if they can be directly included in the source code

- be able to open another debugger on top of the code I see in the debugger. I'm doing the stepping, I'm at a certain point in the method, and I can simply mark the part of the method code that has already been executed or is yet to be executed and start stepping it with the next debugger. This is especially useful for code without side effects. Then I can continue stepping the original method.

- be able to have multiple debuggers open and compare their status

- to have more freedom in the visualization of values and objects. Having them open in other windows independent of the original debugger, being able to interact with them using code (which can be debugged independently)

- be able to save the state of the application and debuggers so that for very hard-to-reproduce errors, I can easily recover the hard-to-retrieve state and experiment with it repeatedly without worrying that I won't get the state again right away

Re: What a good debugger can do

#87

Post by jayd16 »

msoad wrote: post #83

Unfortunately debug-ability usually stops when you have a distributed system in which each part of the system is playing a different song. I wish my job was working on a program that I could run on a single machine. Then I'll look into debuggers. For now I'm `print`ing and hopelessly looking into service logs in DataDog :(

Would certainly be nice to see some of these PAAS offer a distributed debugger that could track RPCs and breakpoint across machines in the cloud. It seems feasible to "step into" a remote method assuming the request IDs were integrated.

Re: What a good debugger can do

#88

Post by jayd16 »

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…

Which of these can't visual studio or intellij do?

Re: What a good debugger can do

#89

Post by q845712 »

Jorengarenar wrote: post #47

>When people say “debuggers are useless and using logging and unit-tests is much better,” Who? Who does say that? Freshman students who barely started coding? >I suspect many of them think that debuggers can only put breakpoints on certain lines, step-step-step through the code, and check variable values. That alone provides enough value to know debuggers are useful.

in my experience a large portion of go programmers seem to think this. I would guess (but haven't confirmed) that there's someplace where rob pike and/or russ cox are on the record telling folks that they don't really need debuggers because printf is great.

Re: What a good debugger can do

#90

Post by AndriyKunitsyn »

akkartik wrote: post #11
AndriyKunitsyn wrote: post #9

Earlier quoted context omitted.

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreove…

But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247

I'm not sure I'm following. A visual debugger ticks a lot of boxes for my needs. Not all - some of them I had to tick myself, but I don't think that trying to reinvent the value that's already there in a debugger, would be particularly productive for me.

As for "forgetting", I don't think I forgot, because, well, I did make a new tool.

The main thing that I wanted to address in the parent comment is that needing tools to debug your code somehow means that the code is a mess - no, sometimes it doesn't.

Post reply on HN