[HN Gopher] Some ways to get better at debugging
___________________________________________________________________
Some ways to get better at debugging
Author : mfrw
Score : 40 points
Date : 2022-08-30 15:15 UTC (1 days ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| wilburTheDog wrote:
| Does #5 sound like a tautology to anyone else?
|
| "In order to know how to solve problems get more experience
| solving problems so you know how."
|
| or maybe
|
| "To know the answers to your questions learn what you need to
| know to answer them"
| ChrisMarshallNY wrote:
| "Good judgment comes from experience. Experience comes from bad
| judgment."
|
| One of my fave quotes (Attributed to "Nasrudin," but usually
| referenced from Will Rogers or Rita Mae Brown).
| memco wrote:
| > adding extra logging
|
| Were that could be done without altering production code or
| restarting production services that don't have any facility to
| change the logging levels on the fly.
|
| Was investigating an issue today in some code that only logged
| that an HTTP request was made to a specific endpoint: no details
| on why it decided to make that request where it was making the
| request from, what the request is expected to do or if it
| succeeded. The unit test approach is the only viable option at
| that level; isolate as little data as possible to replay until it
| succeeds. But that costs a lot of time and may not be safe
| depending on the side-effects. Maybe knowing how to snapshot and
| restore system state should be on the list too?
| horlux wrote:
| you can do that using macros in langs such as c, cpp or elixir
| jrib wrote:
| I'll add two more that I find important to the "Strategies"
| category:
|
| 1. Write things down. Have an assumption? Write it down. Then
| write down how you will test your assumption and the results.
|
| 2. Being able to systematically enumerate possibilities and rule
| them out one by one, often times indirectly. Yes, one needs to
| understand the system but one also needs to have a good strategy
| to use that knowledge. By "indirectly," I mean being able to
| reason like so: If P, then Q. Not Q. Therefore not P.
| chrismatheson wrote:
| Read the stack trace / error message
|
| A lot of the time the answer is there if you read it :)
| ok_dad wrote:
| I have no idea the number of times someone has come and told me
| my code is broken, and when I run it like they did the error
| message clearly indicates the input was incorrect. Sometimes
| even when I detect incorrect input and print a message like
| "input 'manufacturer' must be either 'lexus' or 'toyota'." and
| they still keep trying to input 'bananna' or '3.14159' or
| '{'lexus', 'toyota'}' or something that isn't just 'lexus' or
| 'toyota'!!!
| kelvie wrote:
| Quickly parsing / perusing stack traces is sort of a skill
| that comes from experience (looking at you, large-ass Java
| stack traces with multiple "caused by:"s).
|
| I've noticed this while coaching / working with junior
| developers, is that this is a still that some haven't quite
| developed yet, and others clearly have.
| yawnxyz wrote:
| I think I've spent more time debugging errors (hitting head
| against wall) that come from caching than anything else.
|
| This is some combination of: content cached by Cloudflare /
| Vercel / node server (e.g. using "node cache") / the browser
| (figuring out SWR, why it's working, not working, working too
| well, etc. etc.) / cookies/local storage / PWA settings...
|
| Aside from using browser tools like Chrome's Network and
| Application tabs combined with switching to different browsers
| and outputting a lot of console logs... what tools should I be
| using to get to the root of these issues?
| benreesman wrote:
| I'd like to signal boost strace. It is a lifesaver. In some ways
| it's more important than your compiler: it's how you know what
| wrong-ass directory your compiler is pulling the broken config
| from.
|
| I only know like 10% of the tool and it's just indispensable. Use
| strace!!!!!!!
| omginternets wrote:
| >it's how you know what wrong-ass directory your compiler is
| pulling the broken config from
|
| Mind=blown. Of course! I've been neglecting this thing for so
| many years!
|
| Question: any recommended reading for using strace effectively?
| benreesman wrote:
| `strace` has a bunch of features that I'd like to learn
| thoroughly someday, but I get weekly if not daily value from
| a few basic invocations:
|
| `run_my_build.whatever` -> hangs, damn.
|
| `strace run_my_build.whatever` -> awesome i can see all the
| system calls so i know what `.so`s it's pulling in, and what
| config files it's trying to read, and if it's hanging on a
| network socket or whatever. This is usually where `strace`
| just immediately solves my problem.
|
| If you've got like a background daemon that's misbehaving you
| can do `strace -p <PID>` and it will attach and start
| printing out the syscalls, this can also be really useful.
|
| `strace` (on all my systems at least) logs to `STDERR` by
| default, so sometimes you want some combination of like
| `2>/tmp/log.strace.blah` or to interleave the `STDOOUT` of
| the process so it's just the usual shell stuff `strace
| whatever 2>&1 | rg -C ...`.
|
| My use of the tool is very basic, but that's part of what
| makes it such a great tool, a few simple invocations will
| just save your bacon. This is especially true on a new
| team/company or whatever where you run the thing from the
| Wiki and it doesn't build or start or...
___________________________________________________________________
(page generated 2022-08-31 23:00 UTC)