because life goes on in the cube farm..

post-release activities. memory leak check! o_O

say hello to Valgrind, a mean little tool that sniffs out the memory leaks in your program. we were all given modules to check, and modules to fix.

running valgrind needs to have your program or library running on some environment first, since the executable will be released later on in the program, frank made a script to dupe our program to say "hey! i'm the _ _ _ exe file, run me so I can run a memory leak check test on you since you aren't the first exe running this show."

#!/bin/bash
BIN=fake executable.bin
valgrind --leak-check=full --leak-resolution=high --log-file="actual executable" ./$BIN $*

memory leaks. wtf are they anyway...if you're those computer g33ks, you'd know right away its those memory that is still all over the place after you run a program in C/C++. most of the problems are with regards to the following:

• missing free, delete, delete[] - i admit, i am sometimes at fault with this regard of programming principle.
• mismatched free, delete[] and delete - now this is just....craptastic...enough said.
• unused memory, memory violations and the like - more other troublesome fixes that you have to either know the codes / classes back to back. or you just blindly stab in the dark hoping it's the right memory you're freeing.

so the usual, check line numbers, trace and fix. the missing and mismatched frees and deletes
were easy to fix, but we encountered a problem with the module that still had some leaks ranging from 48 bytes --> n*16 bytes depending on the number of subscribers.

so we had the following clues (same scenario/sequence all through out):

1. an n number of subscribers running has a memleak of (random number) + 16*n
2. infinite loops sequences is okay, doesn't change the memory leak
3. disconnection detection doesn't really affect the memory leak.
4. no leaks of that matter detected on an erroneous gsq file (there was 1, and we fixed that one too).
5. same leak detected on an erroneous cfg file.
6. happened during start of test execution (scenario was target nodes are disconnected), so nothing about execution.

turns out it was a front memory leak for a BUNCH of memory that wasn't deleted in a certain .cpp the formula on number 1 was just the top level memory. the object in question was a certain
dictionary data structure pointer

what's in the pointer anyway? well, it's an array of Node pointers each containing more node pointers inside it (and inside the nodes contain data).

it was enough to bust my brains out. the actual module owner got to fix this problem, with me in the wings. since you really need to know the ins and out of this module for it to run safely, and not accidentally delete a bunch of vital information. so here's that happened:

old destructor of dictionary file:

Nodes::~Nodes()
{
delete []next;
}

sure, it WOULD work, but doing this would delete only the top level array and leave all the memory inside it hanging and leaking and exploding in the background.

so here's the new added code.

Nodes::~Nodes()
{
//ADDED by XXX XXXXX 05/02/2007 XXXXXXX BEGIN
for (int mIdx_i = 0; mIdx_i < nLength; mIdx_i++)
{
if (next[mIdx_i] != 0)
{
delete ( next[mIdx_i] );
}
}
if (Data != NULL)
{
free (Data);
}
//ADDED by XXX XXXXX 05/02/2007 XXXXXXX END
delete []next;
}

this ensures that the node arrays inside of the node array gets cleanly deleted...
and that was the end of the supposed memory leak problems.