Hacker News Reader

Comment by branko_d | Hacker News Reader

Well, if you have a race condition, the debugger is likely to change the timing and alter the race, possibly hiding it altogether. Race conditions is where print is often more useful than the debugger.

View on HN

The same can be said about prints.

Yes, but to a lesser extent.

No, wrong. Totally wrong. You're changing the conditions that prevent accurate measurement without modification. This is where you use proper tools like an In-Circuit Emulator (ICE) or its equivalent.

I think you have a specific class of race conditions in mind where tight control of the hardware is desirable or even possible.

But what to do if you have a race condition in a database stored procedure? Or in a GUI rendering code? Even web applications can experience race conditions in spite of being "single-threaded", thanks to fetches and other asynchronous operations. I never heard of somebody using ICE in these cases, nor can I imagine how it could be used - please enlighten me if I'm missing something...

> You're changing the conditions that prevent accurate measurement without modification.

Yes, but if the race condition is course-enough, like it often is in above cases, adding print/logging may not change the timings enough to hide the race.

Safety systems in aerospace, industrial, and critical sectors use more advanced methodologies than do web developers, and are typically "better" engineers who tend to be familiar with tools and methodologies like debuggers, profilers, tracing, testing, symbolic execution, and (semi/)formal verification. People in low level engineering like kernel, driver, and/or performance engineering tend to be more familiar with such tools and approaches, but aren't as likely to employ as formal or conservative approaches. Security ginreenigne folks should be lumped in for good measure.

> the debugger is likely to change the timing

And the print will 100% change the timing.

Yes, but often no where as drastic as the debugger. In Android we have huge logs anyways, a few more printf statements aren’t going to hurt.

Log to a memory ring buffer (if you need extreme precision, prefetch everything and write binary fixed size "log entries"), flush asynchronously at some point when you don't care about timing anymore. Really helpful in kernel debugging.

Formatting log still takes considerable computing, especially when working on embedded system, where your cpu is only a few hundreds MHz.

Hence the mention of binary stuff.... We use ftrace in linux and we limit ourselves a lot on what we "print".

You don't need to format the log on-device. You can push a binary representation and format when you need to display it. Look a 'defmt' for an example of this approach. Logging overhead in the path that emits the log messages can be tens of instructions.

Reply on news.ycombinator.com