Top Bugs list 

This list is provided for educational purposes for C++ advanced programmers. It includes the most annoying problems we encountered, and spent long hours (months) of debugging to trace and find them, without tools that are available today (like valgrind).

Symptoms "Invalid FP operation" exception in various floating point (FP) operations in the program. No clues.
Trace: first approach Help!
Final investigation Machine code/assembly trace and FPU flags
Solution Some uninitialized (i.e. random by memory content) FP values are invalid. Even simple compare (==) sets the 'invalid FP number' FPU flag, which causes an exception in the next FP operation in a program, or even later.
Symptoms Various program bugs in various places. Various variables are overwritten in memory.
Trace: first approach Help!
Final investigation Machine code/assembly trace of the selected program parts. qsort seems to be responsible. Non-deterministic behavior of the comparison function is responsible. Some qsort implementations rely on the fact that compare(a,b) is deterministic, and if not, will sometimes try to sort a bigger table (so it will overwrite other variables). Another qsort's assumption may be that compare(a,a) returns 0.
Solution Follow qsort assumptions or use another sorting algorithm.
Symptoms Program crashes (invalid memory access) when sorting is involved.
Trace: first approach Only with many qsorts and Borland implementation.
Final investigation Borland implementation uses static variables to store comparison function pointer ("for performance"). Thus qsort cannot be nested (no word about it in docs nor in the source).
Solution Use your own qsort.
Symptoms Strange program/compiler behaviors.
Trace: first approach Good luck!
Final investigation These are compiler errors, we encountered them on various platforms. Sad but true.
Solution Various actions "fix" these problems, but these actions are absurd (like changing order of some source lines or variable names). Extremely hard to figure out "workarounds".
Symptoms Different program behavior when compiled with debug and "release" compiler settings.
Trace: first approach Print out intermediate results and program states.
Final investigation Results of specific functions, machine/assembly trace of internal functions.
Solution Some functions (like sqrt) may differ for debug and "release" compilation/linking. They may for example use double-to-float implicit conversion in debug mode, and the program will behave differently if such minor differences in function results are important. Just be aware.