Memory Leaking During Code Development

Question

While I was developing speller, I ran many load programs before I wrote the unload program. What happens to all of the memory that I allocated while I was developing load before unload got written. Would I eventually run out of memory in my codespace?

Now I have written unload so no memory leaks, but I'm curious about what happens while I was in development.

Answer 1

Would I eventually run out of memory in my codespace?

Possibly. Depends on how much memory is being used up and how much is available.

Very hard question to answer without any context or code to look at.

First, let's define a memory leak. It's memory that's allocated by a program during execution, but for some reason (usually a s/w bug) the program "forgets" about that memory, but the operating system still has it allocated to that program's memory space. If the program runs long enough, that memory leak will allocate more and more memory until it uses up all memory that the OS allocated to the program. Here's an example of a memory leak program that is guaranteed to use up all memory.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>


int main(int argc, char *argv[])
{
    char * point_to_a_memory_address;
    for(int i = 1; i>0; i++)
    {
        point_to_a_memory_address = malloc(1024*1024);
        printf("%i mb allocated\n",i);

    }
}

It's a forever loop, but it will eventually use up all available memory and the OS should kill the program, or hang. (A forever loop without a memory leak would just keep running.) As you can see, this program keeps allocating more and more memory to the pointer without freeing the previously allocated memory. That's an example of one of the most common memory leak errors. Now, had I introduced a free(point_to_a_memory_address); command before the malloc, there would be no leak.

Granted, this is a trivial example, but imagine a production program that ran continually (airline ticketing, google, concert ticket sales, Air Traffic Control, etc.) and say that it was leaking memory consistently because of one small bug in who knows how many lines of code. Now, consider what happens if that memory leak executes thousands of times a minute? See the problem? The result is a program crash.

But, are you describing a memory leak or just incomplete programming? You said it yourself... "before unload got written".

In this case, I believe that you were running valgrind to see what it reported. It saw the dictionary that was allocated, but not freed before the end of the program, simply because the code hadn't been written. It reported what it believes to be unfreed memory, and correctly so. Once you wrote unload, the memory was freed and no memory leak (unless it reported something after the code was completely finished.)

Valgrind will always report any unfreed memory that was allocated during execution. It has no way to know to "ignore this because I haven't written that code yet."

Final piece of advice. One should almost universally avoid looking for memory leaks until the entire program is written and bugged out for any other issues. Many memory leaks can result from other bugs in a program. Better to get rid of all the other bugs first, before wasting time searching for mem leaks resulting from them.

The exception is to use valgrind to find and diagnose certain other issues. Especially common is the dreaded seg fault. It should point you right at the line where the fault occurs (but isn't necessarily the underlying problem.)

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)