You say “cave dweller debugging”, I say debug logging • Hacker News Board

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

#11

Post by danaris » Fri, May 06, 2022, 1:00 PM UTC

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…

If you can show me a debugger that will work on a PHP application in the Symfony framework, runs on Mac, and is not built on Eclipse or a similar lumbering monstrosity, I will gladly give it a try. (Hell, I tried PHPStorm, but it's just so painful to use...)

Until and unless such a thing appears, debug logging is pretty much what I've got.

(And given the complexity of the project in question, and the fact that I'm basically its only developer, debug logging is still pretty vital for running down the bugs the users run into in production. Good thing it's just a free hobby project!)

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

#12

Post by omnicognate » Fri, May 06, 2022, 1:05 PM UTC

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…

I've used lots of debuggers and debugging tools, have a thorough understanding of their capabilities and have written and extended such tools myself. Print statement debugging will always be a tool in my arsenal. Sometimes - surprisingly often - it's just the fastest way to figure something out.

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

#13

Post by zerocruft » Fri, May 06, 2022, 1:09 PM UTC

I use a combination of both. Logging usually requires less setup overhead, so I often opt for that. Sometimes though, the path it takes for the code to reach the part I'm interested in can be pretty obscure. It's in these cases that the debugger truly shines.

It also depends on how many things you are interested in. If you care about, say, a complex object with many properties, then the interactivity of a debugger trumps logging.

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

#14

Post by JoeAltmaier » Fri, May 06, 2022, 1:09 PM UTC

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…

Hm. If its a timing issue, regular debuggers affect that and will perturb the experiment.

Fast, lightweight logging can be a necessary tool.

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

#15

Post by supermatt » Fri, May 06, 2022, 1:21 PM UTC

danaris wrote: post #11

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…

If you can show me a debugger that will work on a PHP application in the Symfony framework, runs on Mac, and is not built on Eclipse or a similar lumbering monstrosity, I will gladly give it a try. (Hell, I tried PHPStorm, but it's just so painful to use...) Until and unless such a thing appears, debug logging is pretty much what I've got. (And given the complexity of the project in question, and the fact that I'm ba…

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

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

#16

Post by tialaramex » Fri, May 06, 2022, 1:27 PM UTC

gary_0 wrote: post #3

I liked this idea in principle but in practice I found there's just too many debugPrint() lines cluttering the code, and too much overwhelming console spam, so it's not worth it to keep around debug logging (or taking the time to decide what is worthwhile to keep). When I fix a problem gnarly enough to require lots of logging everywhere, once I've tidied up I write a detailed comment or other documentation, and/or us…

> overwhelming console spam

The article says to use logging and not actual printf debugging, which solves this. If your logging framework is even somewhat capable and modern it understands all of:

- named priorities: I want that FATAL log highlighted, but I probably don't want the DEBUG log shown at all unless I am currently debugging this

- automatic categories: os.mutex.internal and account.forex.hack can be automatically distinguished in most modern languages by the fact they live in different objects / source code files / even in C we know what the name of the current function is and can at least annotate that in logs.

- how to send the log messages somewhere useful, hopefully at least files and some primitive syslog type protocol, maybe a lot more

In a nice shiny modern logging framework I'd expect to be provided with default annotations so that e.g. when I error.log("Can't enrol students on a module that doesn't exist") the framework annotates the log entry with: The HTTP request that got us here, including e.g. query parameters and date-time stamp, and the Module we were trying to call a method on when it blew up.

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

#17

Post by rkangel » Fri, May 06, 2022, 1:29 PM UTC

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…

There are two situations that I encounter that make step through debugging difficult or impossible, and for a lot of my work both apply.

A) When developing for a microcontroller (however large or small). Stepping debuggers are limited, and sometimes unavailable at all. Most are clunky. ARM is the best here.

B) Running real time things. E.g. you can't step through a Bluetooth comms process because the moment you hit a breakpoint you aren't servicing a link and everything falls over.

There are some good tools like reverse time debuggers (e.g. https://undo.io/) that deal with the real time thing, but nothing deals with the combination. Plus a well maintained set of log outputs often tells you exactly what went wrong with just a cursory glance through the logs.

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

#18

Post by trasz » Fri, May 06, 2022, 1:29 PM UTC

>There are still many situations where it’s not feasible to stop a process, attach the debugger

For example when the person trying to fix it is not a programmer. Human-readable logs are immensely useful for system administrators. Note the "human-readable" - don't dump some random binary garbage or flag values; log something that's actually useful for getting a high-level overview of what's happening.

For example, if you look at FreeBSD's "iscsid -d" output, you'll see this:

  scsid: waiting for request from the kernel
  iscsid: not forking due to -d flag; will exit after servicing a single request
  iscsid: 127.0.0.1: global login_timeout at 60 sec
  iscsid: 127.0.0.1: connecting to 127.0.0.1
  iscsid: 127.0.0.1: Capsicum capability mode enabled
  iscsid: 127.0.0.1: fetching limits from the kernel
  iscsid: 127.0.0.1: setting session timeout to 60 seconds
  iscsid: 127.0.0.1: beginning Login phase; sending Login PDU
  iscsid: 127.0.0.1: key to send: "AuthMethod=None"
  iscsid: 127.0.0.1: key to send: "InitiatorName=iqn.1994-09.org.freebsd:v3"
  iscsid: 127.0.0.1: key to send: "SessionType=Discovery"
  iscsid: 127.0.0.1: key received: "AuthMethod=None"
  iscsid: 127.0.0.1: target requested transition to operational parameter negotiation
  iscsid: 127.0.0.1: beginning operational parameter negotiation
  iscsid: 127.0.0.1: Limits for offload "" are MaxRecvDataSegment=262144, max_send_dsl=262144, MaxBurstLength=1048576, FirstBurstLength=1048576
  iscsid: 127.0.0.1: key to send: "HeaderDigest=None"
  iscsid: 127.0.0.1: key to send: "DataDigest=None"
  iscsid: 127.0.0.1: key to send: "MaxRecvDataSegmentLength=262144"
  iscsid: 127.0.0.1: key to send: "DefaultTime2Wait=0"
  iscsid: 127.0.0.1: key to send: "DefaultTime2Retain=0"
  iscsid: 127.0.0.1: key to send: "ErrorRecoveryLevel=0"
  iscsid: 127.0.0.1: key received: "HeaderDigest=None"
  iscsid: 127.0.0.1: key received: "DataDigest=None"
  iscsid: 127.0.0.1: key received: "DefaultTime2Wait=0"
  iscsid: 127.0.0.1: key received: "DefaultTime2Retain=0"
  iscsid: 127.0.0.1: key received: "ErrorRecoveryLevel=0"
  iscsid: 127.0.0.1: key received: "MaxRecvDataSegmentLength=131072"
  iscsid: 127.0.0.1: target prefers not to do header digest; we'll comply
  iscsid: 127.0.0.1: target prefers not to do data digest; we'll comply
  iscsid: 127.0.0.1: operational parameter negotiation done; transitioning to Full Feature phase
  iscsid: 127.0.0.1: beginning discovery session
  iscsid: 127.0.0.1: key to send: "SendTargets=All"
  iscsid: 127.0.0.1: waiting for Text Response
  iscsid: 127.0.0.1: key received: "TargetName=iqn.2012-06.com.example:target0"
  iscsid: 127.0.0.1: key received: "TargetAddress=127.0.0.1:3260,257"
  iscsid: 127.0.0.1: adding target iqn.2012-06.com.example:target0
  iscsid: 127.0.0.1: removing temporary discovery session
  iscsid: 127.0.0.1: discovery done; logging out
  iscsid: 127.0.0.1: waiting for Logout Response
  iscsid: 127.0.0.1: discovery session done
  iscsid: 127.0.0.1: nothing more to do; exiting

If you (roughly) know how iSCSI works, this will tell you a lot, even if you're not a programmer at all.

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

#19

Post by dgan » Fri, May 06, 2022, 1:39 PM UTC

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

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

#20

Post by daneel_w » Fri, May 06, 2022, 1:40 PM UTC

Caveman debugging is the method that overall has solved the most problems in the least amount of time for me. Some situations obviously request completely different tooling.