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

161–170 of 208 posts

Re: What a good debugger can do

#161

Post by andirk »

thewebcount wrote: post #150
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…

I think one problem I have with gdb and to a lesser extent lldb is that when using them with an IDE, it's just a janky connection between a command-line program and a GUI program. Back in my macOS 7-9 days, using something like CodeWarrior, or even Vusal C++ on Windows, stepping was so fast and smooth. It would respond instantaneously. I can now press the step button like 5 times and watch as it steps to each line. M…

I learned C++ on CodeWarrior (and then vi) and its debugger made me require a debugger whenever I write code. I am currently using PHPStorm (or any JetBrains) and its XDebug debugger.

For Javascript, I use Brave/Chrome debugger.

...And I should use logs more.

I am always in shock when I see people work on large projects with no debugger. I do printf/console.log all the time but HOW DO PEOPLE NOT STEP-STEP-STEP??

Re: What a good debugger can do

#162

Post by snarfy »

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…

Calling Visual Studio 'less powerful' than GDB is telling.

When you have a bug that doesn't happen until hours into your program execution, being able to set a breakpoint, edit-and-continue, and set-next-statement are worth their weight in gold. You can solve in the moment what would take literally days, even weeks using a logging approach.

Sure they both have their place but having a debugger is indispensable, and Visual Studio's debugger is the undisputed king.

Re: What a good debugger can do

#163

Post by turtledragonfly »

snarfy wrote: post #162
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…

Calling Visual Studio 'less powerful' than GDB is telling. When you have a bug that doesn't happen until hours into your program execution, being able to set a breakpoint, edit-and-continue, and set-next-statement are worth their weight in gold. You can solve in the moment what would take literally days, even weeks using a logging approach. Sure they both have their place but having a debugger is indispensable, and V…

> undisputed king

Well, I personally do agree it's a better, more solid overall product. And also agreed that edit-and-continue in some highly stateful situation can be ::chef's kiss::

But I think there is room to dispute its kingliness (:

For instance, scripting GDB with Python is quite nice, on occasion.

Actually, just on Windows, WinDBG has some killer-feature functionality of its own.

Or back with GDB, take, for example, this classic post by Jonathan Blow, where there is some good back-n-forth discussion about GDB vs VStudio, with varying opinions:

* https://news.ycombinator.com/item?id=5125078

Plenty of disputers out there, I daresay.

Re: What a good debugger can do

#164

Post by 13of40 »

Decabytes wrote: post #14

I've always been curious about Debuggers. How do they work? How do they connect to a program and step through it. Why can't more compiled languages integrate debuggers inside of them so that you can debug the program without using a separate tool? And why can't we create interfaces to debuggers so that other text editors can integrate with them, much like how we do we LSPs? *EDIT* Thanks for all the responses! I've n…

> How do they work?

A debugger is basically a very complicated exception handler that can, with the help of the kernel, intercept exceptions from other processes and access their memory. (This is for Windows, but I would guess that Linux is about the same.)

When process X wants to debug process Y:

1. Process X calls into the kernel and says it wants to debug process Y.

2. The kernel verifies that process X is allowed to do that. (You wouldn't want a low privileged user to be able to debug a service, right?)

3. The kernel triggers a debug break exception in process Y, usually.

4. Process X goes into a loop where it asks the kernel for the next exception from process Y, which is a blocking call until Y has an exception.

5. The kernel's exception handler catches the exception and passes details about it back to process X.

6. While process X is in control, process Y is suspended and process X can use other kernel calls to read and write process Y's memory.

7. When process X is done doing whatever, it tells the kernel to continue the previous event and asks for the next exception.

Process X will have, of course, loaded some libraries that help it navigate the structures in memory in process Y, starting with something at a well-known address like the PEB. That lets it do things like enumerate threads and loaded modules, find symbols, etc.

Relevant win32 calls are:

WaitForDebugEvent, ContinueDebugEvent, ReadProcessMemory, WriteProcessMemory

(Standard caveat that I haven't actually written one of these things in 20 years applies. Maybe there's new stuff now.)

Re: What a good debugger can do

#165

Post by cassepipe »

I am personnally a big fan of gdb. There are some things you need to know before it's usable.

1. Use TUI mode with gbdtui

2. Install the packages that will give you syntax coloring in TUI mode (source-higlight something)

3. learn about Ctrl+L or alias `refresh` to `r` t redraw after your program prints if it does

Bonus 4. gdb uses readline just like bash and rlwrap so its command line is configurable with the ~/.inputrc file. I personally enjoy the vi mode. Tons of other options.

Bonus 5. alias gdbtui to `gdb -q -ex start --args` so it shuts up and set a temp breakpoint on you main

Then you basically have a c interpreter under your hand. I remember writing a function for my class that would dump a .dot file based on the state of my tree that I could just call anytime in gdb and see my tree update in xdot. Wonderful time.

Re: What a good debugger can do

#166

Post by turtledragonfly »

andirk wrote: post #161
thewebcount wrote: post #150

Earlier quoted context omitted.

I think one problem I have with gdb and to a lesser extent lldb is that when using them with an IDE, it's just a janky connection between a command-line program and a GUI program. Back in my macOS 7-9 days, using something like CodeWarrior, or even Vusal C++ on Windows, stepping was so fast and smooth. It would respond instantaneously. I can now press the step button like 5 times and watch as it steps to each line. M…

I learned C++ on CodeWarrior (and then vi) and its debugger made me require a debugger whenever I write code. I am currently using PHPStorm (or any JetBrains) and its XDebug debugger. For Javascript, I use Brave/Chrome debugger. ...And I should use logs more. I am always in shock when I see people work on large projects with no debugger. I do printf/console.log all the time but HOW DO PEOPLE NOT STEP-STEP-STEP??

> HOW DO PEOPLE NOT STEP-STEP-STEP

I think I have felt some of what you are feeling. The debugger is ... seductive (: For one thing, it is an educational experience, as you step along you are learning what your program is actually doing, which is a good mental checkpoint, especially when I was a more junior developer. I think a debugger as an educational tool is a big point in its favor. And so you may develop a positive relationship with your debugger, and want to bring it with you wherever you go.

But you may find, as I did, that the sparkle of that relationship fades somewhat in time. You will be better at knowing what the code does, without needing the debugger to tell you. You will hit situations where the debugger cannot help you, or is less helpful than the alternatives. You will get better at structuring your code so certain classes of problems simply don't happen as much, rather than using a debugger to peek-and-poke to fix things all the time. You may find the debugger to be a relatively exhausting high-touch real-time experience, compared to thinking about issues more at your leisure, or getting a larger understanding from other sources.

And so, with experience, and hopefully with an open mind, the debugger will settle into its proper station, in the pantheon of your various debugging aids. Not bad, but not the end-all-be-all either.

I am being somewhat flowery in my language, but all I am saying is: it's okay to rely on the debugger, at some stages. Give it time. Just don't forget about the alternatives or denigrate them needlessly. You want to build a big happy family of technologies and techniques (many of them residing solely in your mind) that can all work together.

Re: What a good debugger can do

#167

Post by Stratoscope »

Where I work (IBM Watson Orders) they sometimes call me "the debugger guy". I love a good debugger and what it can do for me.

I don't use it only for debugging; it's also a great tool to help anyone understand a complex codebase like ours.

Not sure how or why the code reaches a particular function? Set a breakpoint and then look at the call stack. It's all right there.

And if you want to write some experimental code that will execute in the context of that breakpoint, just open the Python console. You can import any modules you need and test your new code immediately.

I also appreciate good logging. Especially when there was a problem yesterday in one of our customer's drive-thrus. I can't attach a debugger, but I've helped make sure we have solid information in the store logs.

Just the other day I was working on some testing code that would send an MQTT message to one of our services, and then it did a sleep(n) call to wait for that service to complete our task. The number of seconds to sleep was pure trial and error. Sleep too long and the tests take too much time to run. Don't sleep long enough and the tests become unreliable.

So I figured I would add a bit of code to that service to send another MQTT event back to the test code after completing its task. Instead of sleeping, the test code would just wait for that signal.

But where to put that MQTT call in the target service? It's a lot of rather complex code. So I slathered that service with hundreds of log.info("abcxyz") calls, every place I could find to put one.

It quickly became apparent from the log where the service completed the task and it stopped logging other messages. That's where I added the "I'm done" signal.

One thing that helped here is that our logging library adds the line number where each log.info() was called. So I didn't have to customize that log message, I could just copy and paste the same log.info() call hundreds of places.

I think every developer should learn how to effectively use both a debugger and logging. Otherwise you're working with one hand tied behind your back.

We had a conversation about this last week, including a link to an article with a title I found astonishing - "Debuggers are for Losers":

https://news.ycombinator.com/item?id=35013732

Re: What a good debugger can do

#168

Post by tester756 »

Stratoscope wrote: post #167

Where I work (IBM Watson Orders) they sometimes call me "the debugger guy". I love a good debugger and what it can do for me. I don't use it only for debugging; it's also a great tool to help anyone understand a complex codebase like ours. Not sure how or why the code reaches a particular function? Set a breakpoint and then look at the call stack. It's all right there. And if you want to write some experimental code…

I call it debugger-driven-development and it is indeed great when you have to get quickly into huge, complex codebases.

It allows you to learn them very fast.

VS has great debugger for C# which allows you to do a lot of stuff when running the program, so sometimes I even develop the soft while having debugger and breakpoints attached

Re: What a good debugger can do

#169

Post by MaulingMonkey »

snarfy wrote: post #162
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…

Calling Visual Studio 'less powerful' than GDB is telling. When you have a bug that doesn't happen until hours into your program execution, being able to set a breakpoint, edit-and-continue, and set-next-statement are worth their weight in gold. You can solve in the moment what would take literally days, even weeks using a logging approach. Sure they both have their place but having a debugger is indispensable, and V…

> edit-and-continue

Breaks on enough codebases for me to not be in the habit of relying on it.

My own "killer feature" of VS debugging is being able to open up a crash dump, have VS auto-download matching pdbs from a symbol server, and auto-view the correct source file version/revision thanks to source indexing - without checking out by hand and turning my build stale. Killer ergonomics.

Sometimes I'll resort to windbg/cdb for memory pattern searches, automation, untangling wow-mangled crashdumps, etc. but VS itself is a nice first resort.

Re: What a good debugger can do

#170

Post by Scubabear68 »

andirk wrote: post #161
thewebcount wrote: post #150

Earlier quoted context omitted.

I think one problem I have with gdb and to a lesser extent lldb is that when using them with an IDE, it's just a janky connection between a command-line program and a GUI program. Back in my macOS 7-9 days, using something like CodeWarrior, or even Vusal C++ on Windows, stepping was so fast and smooth. It would respond instantaneously. I can now press the step button like 5 times and watch as it steps to each line. M…

I learned C++ on CodeWarrior (and then vi) and its debugger made me require a debugger whenever I write code. I am currently using PHPStorm (or any JetBrains) and its XDebug debugger. For Javascript, I use Brave/Chrome debugger. ...And I should use logs more. I am always in shock when I see people work on large projects with no debugger. I do printf/console.log all the time but HOW DO PEOPLE NOT STEP-STEP-STEP??

“HOW DO PEOPLE NOT STEP-STEP-STEP”.

For me it’s because that is slow, tedious and exhausting. Often you need to cover a lot of code surface area to find a bug.

Worse, the bug may be something reported in production in a giant pile of code.

A good set of logs will go a very long way to at least narrowing down where the bad behavior is coming from, and is generally scalabale.

The debugger is useful, but generally only at the extremes of “new to the code, totally clueless” and “really advanced bug that I need to bring out the big guns for”.

The logging approach clicks in really fast the minute you’re talking about a multiprocess program, being microservices or just plain old SOA.

Post reply on HN