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).
| 1. | |
| 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. |
| 2. | |
| 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. |
| 3. | |
| 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. |
| 4. | |
| 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". |
| 5. | |
| 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. |