Debug Programs by Modifying Them

In multi-threaded code or using interrupts (ie. clock or I/O), it's pretty obvious what causes this. Fix can be hard though, but absolutely required for robust execution.

In single-thread code, I've often noticed my assumptions about the code paths were wrong. So print debugging actually improved my understanding of what the logic really is doing. Then, either improving the process, or my assumptions/memory of it. Many times debugging like that removes subtle bugs and mistakes that otherwise would've remained invisible and dormant.

Usually when something is off about the execution, however long it takes, it's usually my own assumptions that's wrong. The program logic just does what it's told, and is usually void of off by one errors and the like. If there's subtle bugs, it's often shallow object clones or mistakes handling complex datastructures that seemingly works.

Debugging is just a tool though, use whatever suits you best. I do like the idea of improved tools like RR. However, you often delve into languages that don't have them, so print debugging remains a useful hammer lying around.

Fully agree with this. More often than not bug is in the computer between my ears rather than the computer on my bench.

Stepping through can be a pain sometimes, because to find certain bugs it's easier to look through a log throughout a longer run of the program, and see how the state changes.

Of course, a debugger that could generate a log like that instead of pausing execution would give you that benefit too.

In my teens, after long programming session, my brain simply refused to understand what I was looking at. These occasions often led me to try to fix bugs by randomly changing the code. Some bugs were mere off by one errors, then I changed for loops to stop earlier, initialized pointers to NULL and early bail out of a function if a parameter was NULL, increased size of arrays...

It worked more often than I'd like to admit. Reading the code later was utter incomprehensible and left a bitter taste. Eventually I stopped using such technique. It was better to leave to code crashing than having it working without knowing why.

To this day I still see inexperienced C programmers making the same mistake. Such fixes are the kind of mess that will make something work on a computer just to crash in another OS or architecture.

The funniest example of such a specimen I saw was a very interesting graph problem solved in C. It worked beautifully. The algorithm was elegant and low complexity but it was not general enough and some cases had to be specially handled. New special cases were discovered and the team had to resort to a few tests that started breaking when other cases were fixed. Bug appeared and were fixed randomly. A last case was fixed and then all the other previous important cases crashed.

What to do? Valgrind to the rescue!

After running the code on Valgrind, success! Not that it helped fix the bugs, there were lots if complaints, but it didn't crash. So, instead of fixing the bugs, the team decided that it was to be run only under Valgrind and everybody was happy.

for poorly written python code that is just too large to add the many print statments.. I run it using trace and pipe to a log.. ofc pdb is awesome too.. provided it crashes so I can work in the stack trace..

for bash I do something similar by using set -x and a custom PS4 prompt that gives me file function and line number..

in my own code I have info, warn, error and debug log lines (for both bash and python).. so I rarely have to resort to enabling trace..