4 ms·

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 differen

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 then? By enabling the debug symbols AND the optimizations and using the debugger, looking at the code and the disassembly side by side and trying to keep your sanity as the steps hop back and forth through the code. Telling yourself that the bug is real and it just cannot be reproduced easily because it depends on multiple factors + hardware states. Ah! I sometimes miss those kinds of bugs which make you question your reality.

K0balt 2y ago
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.
- overfl0w 2y ago
  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 :-)
  - K0balt 2y ago
    Sounds like a fun one. I know Im a broken man because I actually-like- tracking down those kinds of bugs lol.
sixthDot 2y ago
yeah, printf is not "pure", it can modify CPU flags so it's not always an adequate tool.

K0balt 2y ago

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.

overfl0w 2y ago
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 :-)
- K0balt 2y ago
  Sounds like a fun one. I know Im a broken man because I actually-like- tracking down those kinds of bugs lol.

sixthDot 2y ago

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