Valgrind is your friend

[sje]

Valgrind is your friend

A few weeks ago in a case of too much cleverness, I accidentally introduced a bug in Symbolic where I had coded:

Code: Select all

delete objectptr;

instead of what was needed:

Code: Select all

delete [] objectptr;

And so the program would throw a segmentation fault once every hundred hours or so of operation.

My thought is that an over-reliance on brute force tools like valgrind leads to poor coding practice, much like reliance on calculators leads to atrophy of arithmetic skills, and reliance on spelling correctors leads to atrophy of composition skills.

But sometimes, brute force is the best treatment.
http://valgrind.org/

[JoshPettus]

Oops, Strangly enough I just learned about that one in C++ class last week.

[sje]

I had been bitten by that bug before, back in the late 1990s; I recall the incident distinctly because of the ensuing debugging grief. Since then I've been careful, but not perfectly careful.

Symbolic has 16 instances of "delete [] objectptr;", but somehow I had missed a case where the brackets were mistakenly omitted.

Perhaps the compiler could be modified to emit a diagnostic in the above, or the run time support could check for incorrect deallocation of array objects.

[matthewlai]

Valgrind is your friend

A few weeks ago in a case of too much cleverness, I accidentally introduced a bug in Symbolic where I had coded:

Code: Select all

delete objectptr;

instead of what was needed:

Code: Select all

delete [] objectptr;

And so the program would throw a segmentation fault once every hundred hours or so of operation.

My thought is that an over-reliance on brute force tools like valgrind leads to poor coding practice, much like reliance on calculators leads to atrophy of arithmetic skills, and reliance on spelling correctors leads to atrophy of composition skills.

But sometimes, brute force is the best treatment.
http://valgrind.org/

I would recommend switching to smart pointers to manage your memory. Manual memory management is error prone, and many bugs will never be discovered.

C++11 smart pointers are the best, but if you don't want to switch to C++11, there are also Boost smart pointers.

I don't do any manual memory management anymore in my C++ engine. The whole industry is also switching to smart pointers as best practice.

[geko]

http://www.drmemory.org/ is good too

[mar]

C++11 smart pointers are the best

I assume you're talking about std::unique_ptr in this case.
Consider the following code:

Code: Select all

std::unique_ptr<Class[]> arr(new Class[8]);
std::unique_ptr<Class> arr(new Class[8]);

Both will compile fine but the latter will lead to the same disaster as using delete instead of delete[]. Typos can happen.

Other than that I don't understand Steven's comment how using valgrind (or drmemory on Windows) leads to bad coding practice.

[matthewlai]

C++11 smart pointers are the best

I assume you're talking about std::unique_ptr in this case.
Consider the following code:

Code: Select all

std::unique_ptr<Class[]> arr(new Class[8]);
std::unique_ptr<Class> arr(new Class[8]);

Both will compile fine but the latter will lead to the same disaster as using delete instead of delete[]. Typos can happen.

Other than that I don't understand Steven's comment how using valgrind (or drmemory on Windows) leads to bad coding practice.

Yeah I meant std::unique_ptr and std::shared_ptr.

I never use smart pointers for collection of objects. I use containers for that (usually std::vector). I only use smart pointers for single objects.

[bob]

C++11 smart pointers are the best

I assume you're talking about std::unique_ptr in this case.
Consider the following code:

Code: Select all

std::unique_ptr<Class[]> arr(new Class[8]);
std::unique_ptr<Class> arr(new Class[8]);

Both will compile fine but the latter will lead to the same disaster as using delete instead of delete[]. Typos can happen.

Other than that I don't understand Steven's comment how using valgrind (or drmemory on Windows) leads to bad coding practice.

I think he was talking about giving the responsibility for finding memory addressing problems to a third party (such as valgrind) as opposed to taking that responsibility as your own.

[sje]

Other than that I don't understand Steven's comment how using valgrind (or drmemory on Windows) leads to bad coding practice.

I think he was talking about giving the responsibility for finding memory addressing problems to a third party (such as valgrind) as opposed to taking that responsibility as your own.

Correct. A crutch is beneficial only to the point when it's unneeded.