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

81–90 of 139 posts

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

#81

Post by jayd16 »

geophile wrote: post #77
jayd16 wrote: post #71

Earlier quoted context omitted.

> If you are doing anything involving multiple processes, or distribution, debuggers are useless How so? Can't you just attach to each process? Do you mean at production scale?

Even in development. You could, I suppose, but I'm not sure why you would want to. Going back and forth to two debuggers (at least) seems like torture. And with multiple processes, timing and synchronization issues could make interactive debugging a real nightmare. Why? Why would you do this? Interactive debugging doesn't scale in any dimension.

It's really not that hard, especially if you can run them all from the same IDE. I can see how it starts to get out hand but it's not at n=2.

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

#82

Post by chrsig »

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, so the last and most important tail end of the log doesn't vanish if the app crashes.

It sounds like you're looking for fsync[0]

[0] https://man7.org/linux/man-pages/man2/fdatasync.2.html

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

#83

Post by wruza »

dmurray wrote: post #29
gulikoza wrote: post #7

I'm having the same issues... Although I'm not a full time developer, I do some small coding and I'm also sort of responsible for the dev team. I rarely use a debugger. I do most of debugging through logging. There are 2 advantages that I see: - it forces me to add the logs where they are needed to understand the flow of the application - it forces me to make those logs actually usable, readable and understandable De…

> Making logs during development also forces developers to make a conscious effort of finding a balance of what and when to log something, create proper debug levels not to overwhelm the logs, while still providing some useful information... The need for this balance is why I don't completely agree with the article. If I'm debugging something with log messages, I put way more detail into it than I want to see in prod…

If I'm debugging something with log messages, I put way more detail into it than I want to see in production even at LogLevel.DEBUG.

I mean, there is LogLevel.TRACE when you need it. For those not familiar, this level is exactly for “I’m writing new buggy code where anything can go wrong so stupidest details matter”-time. You can use it to separate normal debug logging like “request body is {…}” from sandbox logging like “loop counter just became [object Object]”.

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

#84

Post by GeorgeTirebiter »

geophile wrote: post #79
10000truths wrote: post #67

Earlier quoted context omitted.

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 termi…

... or you could just log. I don't understand the extreme attachment to interactive debugging that I see in some of the comments here. It's like people are so attached to this idea that they will do anything to make it work as each complication is added. Furthermore, the amount of attention and manual labor needed to use a debugger effectively is just staggering. One mistake, e.g. you step over a function you should…

The lure of gdb is that you do not need to write the logging code.

But I am reminded of the diddy: "If a system has a Powerful Debugger, what does that say about the apparent need for a Powerful Debugger?" --- I read that as: if you have a kick-a* debugger, you have a really complicated system. Maybe the answer is to make the system less complicated.

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

#86

Post by mjevans »

khalladay wrote: post #75
dkjaudyeqooe wrote: post #46

I find debuggers almost entirely useless for two main reasons: (1) 99% of debugging is working out where the error is and (2) the answer to the question "how did this come to be?" usually has an answer involving several bits of code or data far away from each other.

Don't data breakpoints help with both of these things?

Only if you already know the value(s) being watched. If you know that you can also add trace level debug statements on those items in the code.

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

#87

Post by dwaltrip »

Cthulhu_ wrote: post #21
dgan wrote: post #19

when outputting lots of information (like a running game) i found that a "csv-like" format is actually the best compromise between readability and being structured. Just log "header_1;header2;... value_1;value_2;..." you can still grep it, or redirect to a file and parse later

in Javascript applications, you can use `console.table()`: https://developer.mozilla.org/en-US/docs/Web/API/console/tab...

I can't believe I've never heard of this! Thanks

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

#88

Post by geophile »

GeorgeTirebiter wrote: post #84
geophile wrote: post #79

Earlier quoted context omitted.

... or you could just log. I don't understand the extreme attachment to interactive debugging that I see in some of the comments here. It's like people are so attached to this idea that they will do anything to make it work as each complication is added. Furthermore, the amount of attention and manual labor needed to use a debugger effectively is just staggering. One mistake, e.g. you step over a function you should…

The lure of gdb is that you do not need to write the logging code. But I am reminded of the diddy: "If a system has a Powerful Debugger, what does that say about the apparent need for a Powerful Debugger?" --- I read that as: if you have a kick-a* debugger, you have a really complicated system. Maybe the answer is to make the system less complicated.

That doesn't make sense to me. Complication is mainly a property of the software you're writing, not the language in which the software is written.

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

#89

Post by IshKebab »

halostatue wrote: post #68
nicoburns wrote: post #9

Earlier quoted context omitted.

> 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.

That sounds like exactly the sort of situation where you really want to use a debugger! I'd rather wait 3 hours to hit the bug and have full access to everything than wait 2 hours and realise that I didn't log an important variable and have to start again.

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

#90

Post by geophile »

jayd16 wrote: post #81
geophile wrote: post #77

Earlier quoted context omitted.

Even in development. You could, I suppose, but I'm not sure why you would want to. Going back and forth to two debuggers (at least) seems like torture. And with multiple processes, timing and synchronization issues could make interactive debugging a real nightmare. Why? Why would you do this? Interactive debugging doesn't scale in any dimension.

It's really not that hard, especially if you can run them all from the same IDE. I can see how it starts to get out hand but it's not at n=2.

Early in my software career, I was debugging a compiler problem. Version X worked, version X+1 did not. I debugged by tracing both step by step, in two gdb sessions, looking for when behavior diverged. Pure torture, and that was an extremely simple case -- the processes were not communicating in any way.

All the usual problems, but doubled. Oops, I stepped too far, start over. Oops, the other one stepped too far, start over. Oops, start over, oops, start over.

Never again.

Post reply on HN