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

141–150 of 152 posts

Re: Printf debugging is ok

#141

Post by shadowgovt »

fweimer wrote: post #118
shadowgovt wrote: post #24

As with so many categorical guidelines, there are circumstances to use it and circumstances to not. The key insight is that printf() is a heavyweight operation ("What, you want to build a string? A human readable string? Okay, one second, lemme just pull in the locale library..."). If you're debugging something at the business-logic layer, it's probably fine. If you're debugging a memory leak, calling a function that…

Isn't localization triggered for specific format strings only? There are many corner cases when typical printf implementations call malloc, but it's usually not too hard to avoid them. If you are worried about including and potential side effects from that, you can use __builtin_printf instead.

You're correct, but then you're adding the additional burden to your debugging process of memorizing which format strings trigger localization. I'd have to look it up, but I'm pretty sure numbers do, which means anytime you %d or %f you're inviting the devil in.

When I say move memory around in this context, I mean do a lot of stack operations. You can leak from the stack too (drop a pointer from the stack without freeing the underlying heap memory it referenced), and it's harder to catch that if printf has come along and completely rewritten your unused stack memory as consequence of reporting on the state of your program.

That having been said, the point is that context matters and what you're debugging matters for the question of what tool to use. If you're operating in an interpreted language, you can probably trust that The interpreter is making it difficult to leak memory like that. On the other hand, interpreters have bugs too, and using a language that is interpreted instead of compiled machine code makes bugs in the execution layer unlikely, but not impossible...

Re: Printf debugging is ok

#142

Post by 5- »

note that you can also add breakpoints directly to your code, in the same way as printf, no ide needed.

sadly there is no standard way to do this (c++ is reportedly getting one in '26: https://en.cppreference.com/w/cpp/utility/breakpoint), so you just need to use what your platform provides. here's a partial list: https://stackoverflow.com/a/49079078

e.g. __debugbreak in msvc, asm("int3") on x86[_64], raise(SIGTRAP) in posix.

Re: Printf debugging is ok

#143

Post by kmoser »

pantalaimon wrote: post #83
skissane wrote: post #79

Earlier quoted context omitted.

That’s a good idea except it is in another team’s service and I’m not very familiar with their code. But I can try Well, the hard part isn’t actually the code change (reasonably obvious) it is deploying my own copy of their service…

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.

Or modify the token itself so it's no longer valid? (Although that might come back with "invalid token" rather than "expired token.")

Re: Printf debugging is ok

#144

Post by K0balt »

overfl0w wrote: post #136
K0balt wrote: post #130

Earlier quoted context omitted.

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

Sounds like a fun one. I know Im a broken man because I actually-like- tracking down those kinds of bugs lol.

Re: Printf debugging is ok

#145

Post by seanmcdirmid »

throwaway2037 wrote: post #113
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.

> they are often the 1 out of 100 runs kind Can you share an example? In my whole career, I have only seen one or two of them, but most of my work is CRUD type of stuff, not really gaming or systems programming where such a thing might happen.

In Android they are way too common. Like an animation that decides to fire after the UI element it was made for has been destroyed, or a race condition in destroying a resource, or VE logging.

Re: Printf debugging is ok

#146

Post by fweimer »

shadowgovt wrote: post #141
fweimer wrote: post #118

Earlier quoted context omitted.

Isn't localization triggered for specific format strings only? There are many corner cases when typical printf implementations call malloc, but it's usually not too hard to avoid them. If you are worried about including and potential side effects from that, you can use __builtin_printf instead.

You're correct, but then you're adding the additional burden to your debugging process of memorizing which format strings trigger localization. I'd have to look it up, but I'm pretty sure numbers do, which means anytime you %d or %f you're inviting the devil in. When I say move memory around in this context, I mean do a lot of stack operations. You can leak from the stack too (drop a pointer from the stack without fr…

Admittedly, I forgot about %f/%g and the decimal separator. I think the rest is fairly obscure (such as %lc for wide character to multibyte character translation). For integers you need %Id (variant digits) or %'d (grouping).

The decimal separator is a bit of a problem for JSON generation, too. Some systems have snprintf_l, but it's not very widespread.

Re: Printf debugging is ok

#147

Post by bee_rider »

bee_rider wrote: post #77
pryelluw wrote: post #18

Earlier quoted context omitted.

I’d say programmers are taught to nitpick away at arguments by default. The nature of the code review is to verify that the code I wrote meets certain (opinions) standards. Hence nitpicking is built into the profession. Maybe one day it’ll improve. Till then, I’ll continue arguing about everything there is :-)

I wouldn’t say programmers are taught to nitpick, so much as look for non-obvious problems. The nitpicking comes as a side effect. Maybe it is cargo-culting.

(This is a meta-nitpicking joke).

Re: Printf debugging is ok

#148

Post by sixthDot »

That post does not mention how contracts can help as preliminaries clues on the nature of the bugs.

Sure you can printf or run gdb, or whathever, but first if something like a contract has failed it will be easyer.

Re: Printf debugging is ok

#149

Post by sixthDot »

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…

yeah, printf is not "pure", it can modify CPU flags so it's not always an adequate tool.

Re: Printf debugging is ok

#150

Post by from-nibly »

Too wrote: post #82
from-nibly wrote: post #67

Print debugging us for when you have a quick itteration cycle. I don't know what debuggers are for because if you don't have a quick itteration cycle you should be killing yourself to have a quick iteration cycle.

On the contrary, adding print statements increases iteration time, because you need to edit the file, recompile and relaunch the program. Whereas adding a breakpoint is just one click in the margin of the editor.

And then what? Don't you need to edit the program, recompile, and relaunch the program? My point is if edit, compile, relaunch isn't fast you need to figure out how to make it fast because that's what you are doing all day anyway. Working around that only for debugging is a waste
Post reply on HN