Thread: Memory leak

Originally Posted by MK27

That's only true WRT "any kind of bug" -- no amount of testing can demonstrate there are no possible bugs of any sort. However, testing can demonstrate that no bug of a particular sort exists, such as a memory leak. At exit, valgrind will give you an allocated/free summary and say "All heap blocks were freed -- no leaks are possible", by which I do not think they mean "nothing is true, everything is permitted", or "there may be leaks, just we did not find any involving your computer's memory", etc.

There may be plenty of cases where that method won't work, and I've never used it myself, but I think there are plenty of cases where, logically, it will work perfectly.

"No leaks are possible" would be more correctly interpreted as "It is possible there are no leaks" rather than your "It is impossible there is a leak". You clearly prefer to believe the latter.

Effective usage of tools like valgrind relies on defining a set of test cases that exercise all possible program flows that affect the relationship between memory allocation and deallocation. If valgrind reports no leaks, that only means the executed test cases do not result in leaks. It does not mean that other test cases (or, worse, user behaviours after release of your program) will not result in leaks.

Originally Posted by grumpy

"No leaks are possible" would be more correctly interpreted as "It is possible there are no leaks" rather than your "It is impossible there is a leak". You clearly prefer to believe the latter.

Effective usage of tools like valgrind relies on defining a set of test cases that exercise all possible program flows that affect the relationship between memory allocation and deallocation. If valgrind reports no leaks, that only means the executed test cases do not result in leaks. It does not mean that other test cases (or, worse, user behaviours after release of your program) will not result in leaks.

Ah yeah, the good old "user behaviours". I wish there were a tool that can solve stupidity and ignorance. :P

Originally Posted by CommonTater

There is... it's called "Properly error trapped programming"...

That is actually necessary but insufficient. The range of techniques for checking errors in input are finite, but the set of possible runtime errors are infinite - particularly with compromised hardware.

One fatal assumption virtually all programmers make is to assume that the hardware behaves as the software expects it to.

Originally Posted by CommonTater

There is... it's called "Properly error trapped programming"...

Input is always harder than output...

Don't underestimate human's "ingenuity". I've worked at a company that manufactured arcade prize vending machines. And from the site tests and the client's reports, the players's behaviors were unthinkable. They kicked the machine, brought a portable battery/accu to short the machine, etc. All to win the prize. A few of them worked, a few of them not, all of them hazardous to the machine.