“Exercise good memory-related coding practices by creating a comprehensive program to keep memory errors under control. Memory errors are the bane of C and C++ programming: they’re common, awareness of their importance for over two decades hasn’t eradicated them, they can impact applications severely, and few development teams have a definite plan for their management. The good news, though, is that they needn’t be so mysterious.”
Whilst good programming practices are always better than debugging I’m surprised that the author didn’t mention valgrind:
http://valgrind.org
It makes very hard to track errors (use of uninitialized values, leaks, double frees, buffer overflows, etc…) extremely easy to spot and fix, it’s really a boon.
I really think the solution is to not use a framework where memory leaks are allowed. Thus, garbage collection has become the norm. Even in the C++ world, I would use “safe” pointers, and there are frameworks that greatly assist in memory allocation/deallocation. Myself, I don’t want to ever go back to manually ensuring errors like memory leaks, null pointers, array boundaries, etc, do not occur. These things should be dealt with at the framework level, or even at the language level. The only exception to this for now is at the OS level (such as drivers, kernels), where the overhead is too much. However, even that will probably change some day.
I’m a programmer, and my philosophy is never trust the programmer. The same goes with the Database. Enforce your business rules at the database level. There is more overhead to database constraints, etc., but I believe the price is worth it.
Using GC is well and good, but ever try debugging a GC
When your GC is freeing stuff out from under you, you want Valgrind…
More seriously, what would you say your most interesting memory management bug has been? I had a nice one where somebody was smashing the stack by allocating large (MBs) structures on it. Took me a full weekend to track that one down.
More seriously, what would you say your most interesting memory management bug has been? I had a nice one where somebody was smashing the stack by allocating large (MBs) structures on it. Took me a full weekend to track that one down.
Mine was a bug in a garbage collector, every time an allocation crossed a 16 MiB boundary the radix-tree which was used for mapping the heap did get subtly corrupted, this caused any kind of weird behaviour and took me three days to figure out (and an insane amount of gdb watchpoints).