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

Printf debugging is ok

polymonster.co.uk

Post reply on HN
Print view View original

131–140 of 152 posts

Re: Printf debugging is ok

#131

Post by poincaredisk »

GuB-42 wrote: post #125

I have changed my mind a couple of times on that subject. My opinion now is that printf debugging is not ok, but that it is not your fault. printf debugging is a symptom of poor tooling. It is like saying that driving in nails with a rock is fine. It works, but the truth is that if you are using a rock, that's probably because you don't have a good hammer. And if on every job site, there are seasoned workers banging…

Maybe, but it's also the only method that works everywhere. I write very different things - python scripts, scripts for weird programs that use ancient or weird languages, web applications, binary exploits, I do small patches to large projects - most recently a custom LLVM pass. With maybe exception of web dev, having a toollit for debugging every of that kinds of software would be hard to impossible to get.

Re: Printf debugging is ok

#132

Post by johnisgood »

roca wrote: post #110
seanmcdirmid wrote: post #64

Earlier quoted context omitted.

The crashes/bugs I deal with are rarely straight down failures, they are often the 1 out of 100 runs kind, so printf debugging is the only way to go really. And I used to be big on using debuggers, but now I’m horribly out of practice.

Record-and-replay debuggers are often better than anything else for debugging intermittent failures: run the program with recording many times until you eventually get the bug, then debug that recording at your leisure; you'll never have to waste time reproducing it again.

I'm very rusty when it comes to debuggers.

Where may I read about particular workflows involving debuggers, e.g. gdb?

(Mainly for programs written in C.)

Most of my issues are related to issues with concurrency though, deadlocks and whatnot.

Re: Printf debugging is ok

#133

Post by [deleted] »

overfl0w wrote: post #128
victorNicollet wrote: post #127

One of the hardest bugs I've investigated required the extreme version of debugging with printf: sprinkling the code with dump statements to produce about 500GiB of compressed binary trace, and writing a dedicated program to sift through it. The main symptom was a non-deterministic crash in the middle of a 15-minute multi-threaded execution that should have been 100% deterministic. The debugger revealed that the cont…

Those are the kind of bugs one remembers for life.

[deleted]

Re: Printf debugging is ok

#134

Post by K0balt »

GuB-42 wrote: post #125

I have changed my mind a couple of times on that subject. My opinion now is that printf debugging is not ok, but that it is not your fault. printf debugging is a symptom of poor tooling. It is like saying that driving in nails with a rock is fine. It works, but the truth is that if you are using a rock, that's probably because you don't have a good hammer. And if on every job site, there are seasoned workers banging…

The nice thing about printf debug is the preemptive debugging. You can leave them in the source as conditional comments, and it makes the code self documenting at runtime. I find it useful as a pre-source review step reopening a project after a few years. Documentation at runtime gives a faster mental map of the execution then reviewing the source without seeing the runtime debug flow.

So my debug builds often self document at runtime, and in production the printfs become comments.

Re: Printf debugging is ok

#136

Post by overfl0w »

K0balt wrote: post #130
overfl0w wrote: post #126

And then there are those rare cases where inserting a print or a new condition to use for conditional breakpoint forces the compiler to output slightly different code which does not produce the bug. Essentially this is similar to the Observer effect in quantum mechanics where the system is disturbed simply by observing it. Also the bug cannot be reproduced with optimizations disabled. How are those cases debugged the…

Those kinds are almost never that the bug isn’t created unless you don’t put in the printf, it’s that the bug only causes the overt manifestation when the printf isn’t there. The actual bug is almost always there in both situations. It’s almost never the compiler. It’s almost never an error in the bare metal. Almost.

The bug in question was a out of bounds writing to a stack allocated buffer. The compiler would choose to store some variables to registers for optimization purposes. When calling a function - these registers' contents would get pushed to the stack. The faulty called function would modify those same register contents on the stack. When returning to the parent function and restoring the context - the registers would have faulty values.

When adding a print or a check - the compiler would choose different variables to store in the registers. They would still get overwritten by the faulty function but the bug would not be observed.

I agree that it's almost never the compiler's fault though - but sometimes its optimization choices make it harder to reproduce a bug.

Edit: The faulty function was a somewhat standard function, part of the SDK. This taught me that the standard functions are almost never faulty. Until they are :-)

Re: Printf debugging is ok

#137

Post by anal_reactor »

Printf debugging is best debugging because it's the only technique available in all environments. You've just learned to use Visual C++ debugger? Great, here is some Python code to debug. Or maybe the bug is in a bash script that only works within a container on a cloud. Or is it the ansible deployment script that is wrong? IDK, have fun, use your debugging skills.

Re: Printf debugging is ok

#138

Post by lolc »

GuB-42 wrote: post #125

I have changed my mind a couple of times on that subject. My opinion now is that printf debugging is not ok, but that it is not your fault. printf debugging is a symptom of poor tooling. It is like saying that driving in nails with a rock is fine. It works, but the truth is that if you are using a rock, that's probably because you don't have a good hammer. And if on every job site, there are seasoned workers banging…

Often I want to know the sequence of some events, what points are reached. Adding print statements is a quick way to trace that. How can tooling make that more convenient?

Re: Printf debugging is ok

#139

Post by majewsky »

skissane wrote: post #90
pantalaimon wrote: post #83

Earlier quoted context omitted.

Can you just set the local time two hours into the future? Or modify the expiry time locally / not use the one from the token at all.

The token isn’t being verified in my service it is being verified in a remote service. I can’t easily change the clock on the remote service. It runs in a K8S pod and (AFAIK) K8S doesn’t support time namespaces. And even if it does, the pod is deployed by a custom K8S operator so unsure if I could make the operator turn that on even if it is available. And the remote service is a complex monolith which uses lots of R…

Reminds me of the classic adage that "everything can be solved by another layer of abstraction, except for the problem of too much abstraction layers".

Re: Printf debugging is ok

#140

Post by bArray »

amszmidt wrote: post #122
bArray wrote: post #120

Honestly, it's just about doing what is easier at the time. Re-compiling an application in debug can be a pain sometimes, or getting back to a specific state within the application to inspect what is going on. Some have mentioned about hardware (which marches on with or without software running), but similarly part of a system where you only really control one sub-system/interface. My print statements normally come w…

Well, yes .. it is a label, and a label can be put almost anywhere. This is normal, expected C behavior and any standard conformant compiler would behave the same, not just GCC.

I think it should at least warn that it is not used by default, or recognise that unused labels within switch statements are likely to be a mistake.

Anyway, the point was, my tired eyes did not easily grep the spelling mistake, hence the print statements.

Post reply on HN