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

131–140 of 208 posts

Re: What a good debugger can do

#131

Post by kaba0 »

macjohnmcc wrote: post #124
RMPR wrote: post #121

Earlier quoted context omitted.

20+ years is... a lot. I do agree with the sentiment though. At first I was printf debugging because didn't know better. Then discovered debuggers and my mind was blown. But when I reached the point where I hit bugs that would magically disappear when running the program through a debugger, I finally understood that there's value in becoming good at both debugging styles.

Debugging issues with multithreaded code can be difficult because you could be looking at race condition that only happens when the code is running at full speed and debugging pausing one or all threads could give you an different experience than the real world.

(Debug) logging can also change the frequency/order/synchronization of threads masking over race conditions.

Re: What a good debugger can do

#132

Post by aidenn0 »

sebastianconcpt wrote: post #123
aidenn0 wrote: post #68

Earlier quoted context omitted.

To qualify as "time-travelling" You should at a minimum be able to step and run backwards and inspect the values of variables at a previous point in time. Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. To meet the standard of the "perfect debugger" from the TFA intro, I would say you should be able to run backwards, modify a function, and run forw…

Yeah. That's the normal way to work for a Smalltalk debugger. I remember once debugging a thread without killing it. I've asked a customer to click on a link that would get to a bug while having remotely opened the IDE that was serving that user session, setting a conditional halt. Seen it halting, fixing the bug and saving the method with the halt removed and let the thread run. All the user saw was a long request t…

I don't see any "running backwards" mentioned in this story. I'm familiar with "break, fix, restart" debugging from Lisp (which had a lot of cross-pollination with smalltalk)

Re: What a good debugger can do

#133

Post by bornfreddy »

aflag wrote: post #84
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

Thank you for the link, well worth the read.

Re: What a good debugger can do

#134

Post by bornfreddy »

justeleblanc wrote: post #118
maleldil wrote: post #66

Earlier quoted context omitted.

> Who? Who does say that? Freshman students who barely started coding? Example from this thread: https://news.ycombinator.com/item?id=35098434

Do we know if that person is a freshman student who barely started coding?

There are many other experienced devs (me included) who simply don't see debuggers worth the effort in most cases. There are exceptions and every competent dev should know how to use one, but to me it is like using crutches - I run faster and better without them. I did use debuggers at the beginning though, a lot too. Then I learned to think about problems and to simplify design of the code, making debuggers much less useful.

Re: What a good debugger can do

#135

Post by hinkley »

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.

There are a lot of middle to late career developers who write code that is difficult to debug. It's a feedback loop. You write garbage code, the debugger is confusing, so you use the debugger less, so you get less feedback on your garbage code, until eventually other people can't debug your code either, or only invest the energy to do so when something has gone horribly wrong.

Or you write debugger-legible code, you use the debugger, and you get feedback when the code you wrote confuses the debugger, so you refactor it to be easier to diagnose the problem, then you commit those changes.

Re: What a good debugger can do

#136

Post by crabbone »

turtledragonfly wrote: post #95

I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a "printf debugging" aficionado (or better: real logging). I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it's a buggy, fuzzy, moving target i…

> It is simple and trustworthy.

This sounds so naive for someone with 20+ years in the field...

Linux, for decades, couldn't get logging to the point that it at least doesn't lose messages (the problem with tail / logrotate that is quite obvious once you think about it, but it took many years to give up the approach).

I recently hit a bug where NVidia's driver abuses Linux kernel logging in some tight loop by spamming log messages at insane speed (happens when you have two video adapters, Intel and NVidia and an external monitor). An interesting side-effect here is that Linux logging tries to throttle loggers who output too much, so, from the log you cannot tell what's happening (because even though the system is burning calories trying to print a tonne of messages, nothing really gets printed).

Several iterations ago I worked on a product where logging had to be implemented as writes to shared memory self-styled circular buffer, and because there was too much info printed too quickly you only had few seconds worth of logs before system crash... on a good day.

Needless to mention the fun of stitching together logs coming from different places in your system with separate clocks.

Even simply processing hundreds of Gigabytes of logs on its own isn't a trivial task.

----

Many things are simple, when your task is simple. Logging is just one of those things.

Re: What a good debugger can do

#137

Post by macjohnmcc »

kaba0 wrote: post #131
macjohnmcc wrote: post #124

Earlier quoted context omitted.

Debugging issues with multithreaded code can be difficult because you could be looking at race condition that only happens when the code is running at full speed and debugging pausing one or all threads could give you an different experience than the real world.

(Debug) logging can also change the frequency/order/synchronization of threads masking over race conditions.

Yeah I had to debug some code with 5 threads that were supposed to be synchronized through the use of several semaphores that was a bear to pin down.

Re: What a good debugger can do

#138

Post by aflag »

justeleblanc wrote: post #119
aflag wrote: post #84

Earlier quoted context omitted.

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

At least he did 23 years ago. Have debuggers evolved in the past 23 years?

They have a little. But his main point is that debuggers distract developers from seeing the problem as a whole rather than just understanding what's going on the vicinity of that problematic line. So, the debugger incentivises small, targeted fixes rather than bigger solutions for more systematic problems.

That aspect of debuggers hasn't changed in 23 years, because that's the whole point of debuggers anyway.

Some projects are better off with a debugger and some developers are more productive with them. But also the other end of the spectrum exists: projects that are better off without and developers who are more productive without them. Not liking debuggers don't mean someone is stupid or inexperienced.

I'd even dare say that's more likely an experienced developer to not use debuggers as much as people earlier in their careers. Seasoned developers working for a long time in the same code base are more likely to have insight of what's going on without stepping through the process execution.

Re: What a good debugger can do

#139

Post by crabbone »

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…

My guess is that you could attempt something like this by recording system calls as your program executes and then replay them in whichever order you need.

You would need a lot of storage space for some programs, but in simple cases that might still be useful.

So, in your example, playing the program back wouldn't really try to read from a closed socket, it would just hit debugger's database of stored system calls at a particular point and retrieve the stored response from that call.

This could get weird though if the program modifies itself as it executes. Not sure what to do in such case, but maybe there's a way to deal with it in special cases, not in general...

Re: What a good debugger can do

#140

Post by kaba0 »

_gabe_ wrote: post #21

> I should mention that the perfect debugger doesn’t exist It may not exist, but this demo has got to be the closest thing to the perfect debugger I've ever seen: https://youtu.be/72y2EC5fkcE

Wow, that’s absolutely insanely cool!
Post reply on HN