Hack that Code!
I have a not-so-secret technique that I use whenever I encounter a bug that evades my grasps. Or when I am lazy. Okay, mostly when I am lazy.
The idea is no more than applying the concept of binary search to source code:
- Remove half the code
- Compile and run
- If the bug is still present, repeat with the remaining code
- Otherwise, repeat with the code that was removed in 1
Of course, this naive approach is rarely practical. For once, removing half the code indiscriminately tend to make things not compile. Also, sometimes, a bug manifests because of the way the first half and the second one interact.
So, in practice, it looks more like:
- Remove some big chunk of code
- If that fails to compile/run, try another chunk, or reduce the size
- Compile and run
- If the bug is still present, repeat with the remaining code
- Otherwise, put back the chunk of code, and try removing another one (can be a sub-chunk of the initial chunk)
Note: sometimes, you will still need to do mini-refactor to keep making progress
This works surprisingly well. And it is very satisfying to remorselessly hack through code that was written painstakingly over hours, months or even years. And then, getting to a small subset of code that clearly exemplify the bug.
Automate the Fun Parts
Software engineers might be the group of people who work the hardest to make themselves redundant.
So, of course, someone already automated the process I described above. It is called C-Reduce. It is meant to find bugs in the compiler rather than in the compiled program, but the principle is the same. If your program is C and you can write a small script that test whether the bug is present, then it will automatically slash through your code.
To give you an idea, consider the code below.
#include <stdlib.h>
#include <stdio.h>
void f(void) {
int x = 42;
int y = 83;
int z = 128;
printf("%d\n", x + y);
}
void g(void) {
int x = 1;
int y = 2;
int z = 3;
printf("%d\n", x + y);
}
int h(void) {
return 42 * 43;
}
int main(void) {
h();
f();
}
#include <stdarg.h>
#include <time.h>As well as the following Bash script.
#!/usr/bin/env bash
set -Eeuo pipefail
gcc -o main main.c
./main | grep -q ^125$
Then creduce test.sh main.c reduces the C source file to:
main() { printf("%d\n", 42 + 83); }This was really a toy example, but that this program is very useful when you have large source files. For instance, C++ ones *shivers*.
Audio Millisecond Mistiming
I have been writing on a tool to practice Morse code using jscwlib, the library behind LCWO. I want to play an infinite flow of words in Morse code. The algorithm is the fruit of decades of research:
- Play a word
- When it has finished playing, play another word
While dogfooding, I realized that the speed sometimes increased unexpectedly. This was subtle enough that I did not notice the transition from normal speed to the higher speed.
Over my next practice sessions, I kept an eye ear on this phenomenon, and eventually realized that:
- The space between the words did get shorter
- The duration of the characters remained the same
From the two first points, I was able to devise a more reliable way to detect the presence of the bug. First, I made all the words just the letter “e”, which is a single “dit” in Morse. Second, I measured the time between the start of two words with new Date(). Finally, I showed the durations on the console.
This is not a very precise method but, it enabled me to see the duration of spaces reducing millisecond by millisecond over a few seconds. The effect became noticeable after a few hundred words were played.
With this, I could test the presence of the bug in mere seconds, instead of minutes of practice. So I went slashing.
After a short while, I found the culprit, wrote a fix, and opened a PR!
Conclusion
In the end, it took me much more time noticing the bug, understanding what it looked sounded like, and finding a way to check for it effectively, than actually identifying its origin in the source code.