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

You say “cave dweller debugging”, I say debug logging

sicpers.info

Post reply on HN
Print view View original

61–70 of 139 posts

Re: You say “cave dweller debugging”, I say debug logging

#61

Post by mirceal »

geophile wrote: post #48

I have become less and less enamored of gdb (or IDE equivalent) debugging over my many years in software. Debugging is often very confusing with multithreaded code. It only works in one language at a time. If you're doing Java with JNI for example, the code called through JNI is a black box. If you are doing anything involving multiple processes, or distribution, debuggers are useless. But the real problem, and top-l…

If you're at the point where you need to attach a debugger, in production, you have already lost. I don't care how much you like debuggers and debugging. Anything, but the most trivial, single-threaded code will be problematic to debug.

So? What do you do? Logging at the right level + turn up logging. Metrics - proper metrics. Core dumps. Debugging turns into an exercise of grepping/inspecting the logs/metrics and/or working with the dump. Anyone that tells you differently is massaging the truth.

Re: You say “cave dweller debugging”, I say debug logging

#63

Post by guhidalg »

mirceal wrote: post #61
geophile wrote: post #48

I have become less and less enamored of gdb (or IDE equivalent) debugging over my many years in software. Debugging is often very confusing with multithreaded code. It only works in one language at a time. If you're doing Java with JNI for example, the code called through JNI is a black box. If you are doing anything involving multiple processes, or distribution, debuggers are useless. But the real problem, and top-l…

If you're at the point where you need to attach a debugger, in production, you have already lost. I don't care how much you like debuggers and debugging. Anything, but the most trivial, single-threaded code will be problematic to debug. So? What do you do? Logging at the right level + turn up logging. Metrics - proper metrics. Core dumps. Debugging turns into an exercise of grepping/inspecting the logs/metrics and/or…

I agree. In today's world of cloud services, good logging is the single most important way to debug issues.

Re: You say “cave dweller debugging”, I say debug logging

#64

Post by verdagon »

kevin_thibedeau wrote: post #60
throwaway894345 wrote: post #49

Earlier quoted context omitted.

I don't know that there's an easy solution to this problem, but what I've seen Kubernetes and other Google-derived projects do is replace standard log levels with an increasing series of integers so you can log in increasing detail. This seems a little arbitrary (one developer's 8 might be another developer's 14 or something) but at least you can easily ask for increasingly more detail until you get what you need wit…

This just creates a festering problem because devs are given too much freedom. A better solution is just two levels, basic and verbose, with subsystem feature flags you can control to prevent verbose from being a fire hose.

That sounds promising. Ever done it this way? Howd it turn out?

Re: You say “cave dweller debugging”, I say debug logging

#65

Post by gpderetta »

GnarfGnarf wrote: post #39

There is a time and place to step through the code with a debugger, and there are also situations where a log file can show the "big picture" and display information at a higher level. In the latter case, a log can show in minutes what would take hours to ascertain if stepping through line-by-line. My app formats the trace log as HTML tables, and uses color to signal errors or invalid cases. Makes debugging fun. Also…

> Tip: close & re-open the file for each write

That seems very expensive. Why not just use line buffering or even flush from a signal handler?

Re: You say “cave dweller debugging”, I say debug logging

#66

Post by AcerbicZero »

I messed up pretty badly when I learned IT. To be fair, the Army isn't a great IT teacher, but I started my scripting life with Powershell (gasp) and worse, Powershell Integrated Scripting Environment (double gasp). They had an awesome thing called the "Powershell scripting games" and I managed to convince the government agency I was working for that counted as work for a week or two. Downsides of powershell aside, it did jumpstart me into coding...

However, one of the horrible habits it gave me that I absolutely adore now is having an interactive REPL for everything. If I want to understand anything inside my code, I can run just that little tiny bit, spit out the answers I need, and move forward. Half the time the best part was just having an open powershell session connected to the same env as the script. For me, it was the first time experiencing scripting with almost no downtime between iterations (most of the time) and the ability to inspect any/every object in play mostly seemessely. I moved on from Powershell to Python/Ruby, but I've basically gone all in on Ruby (devops, no one cares what I write code in) because I am just so much more productive with Pry and the other Ruby REPL options.

It seems to come back to bite me fairly often, but despite trying every ~12 months or so to learn a better way to work with the code, I never seem to find anything that sticks consistently. CodeRunner/random extensions in VS Code, REPLit.com, all the IDE's I could think of....no joy. REPLit comes extremely close, but its online only and that becomes an issue almost immediately. Still, REPLit is amazing when you just get pissed at a random python script that's spitting out junk and you want to figure out how a specific function works.

Maybe I'm missing something? Maybe I need to learn to code the "right" way? Maybe I'm just burned out? Idk, I will literally try any IDE/Tool that hints at giving me a better REPL experience or teaches me a better way to do it.

Re: You say “cave dweller debugging”, I say debug logging

#67

Post by 10000truths »

geophile wrote: post #48

I have become less and less enamored of gdb (or IDE equivalent) debugging over my many years in software. Debugging is often very confusing with multithreaded code. It only works in one language at a time. If you're doing Java with JNI for example, the code called through JNI is a black box. If you are doing anything involving multiple processes, or distribution, debuggers are useless. But the real problem, and top-l…

Working with gdb is quite the learning curve. Luckily, it’s mostly unnecessary, except in the rare case where you actually need register-level debugging or hardware watchpoints. But it can still be done if you’re willing to suffer through the docs.

For debugging multithreaded code, you can run a gdb script in batch/non-interactive mode, and direct the gdb output to some out-of-band channel, like a file or other terminal session.

For debugging JNI, you can try running Java under gdb and set a breakpoint on the extension library entry function before it’s loaded.

Re: You say “cave dweller debugging”, I say debug logging

#68

Post by halostatue »

nicoburns wrote: post #9
supermatt wrote: post #2

No doubt there is a place (or indeed a need) for debug (or trace) logging in environments where you can’t simply pause execution. However, in development environments you would be foolish not to use the (vastly superior) tooling available. I think many developers shy away from debuggers simply because they haven't taken the time to understand how to use them effectively, whereas everyone knows how to write a log stat…

> However, in development environments you would be foolish not to use the (vastly superior) tooling available. The debugger being vastly superior is highly dependant on what environment you are running in.

I have had cases where it takes ~2 hours to hit a bug case. You cannot afford that time waiting for the debugger. You must achieve that with logging. You might be able to figure out, with that logging, how to hit the bug faster and then you can use the debugger to step through, but I have found the use of a debugger to be beneficial in fewer than 20% of bugs I am trying to solve.

Re: You say “cave dweller debugging”, I say debug logging

#69

Post by kerblang »

AcerbicZero wrote: post #66

I messed up pretty badly when I learned IT. To be fair, the Army isn't a great IT teacher, but I started my scripting life with Powershell ( gasp ) and worse, Powershell Integrated Scripting Environment ( double gasp ). They had an awesome thing called the "Powershell scripting games" and I managed to convince the government agency I was working for that counted as work for a week or two. Downsides of powershell asid…

Nothing particularly wrong with Powershell, esp. given how much it's used with MS infrastructure; it's a high-value skill in IT shops everywhere, including the DOD's own. Nothing wrong with REPL's either.

The original author's point about debug logging remains, however.

These are all tools in your toolbox that fit different circumstances differently. Challenge yourself to learn new tools.

Re: You say “cave dweller debugging”, I say debug logging

#70

Post by gpderetta »

danaris wrote: post #27
supermatt wrote: post #15

Earlier quoted context omitted.

I dont personally use PHP so I cant really vouch for it, but I just asked a friend and he uses Xdebug in vscode (on an M1 mac).

Hm. I'll give that a try and see if it's worthwhile. Thanks.

Was that a conscious invocation of Cunningham's law? :)
Post reply on HN