Still reachable memory?

Question

I'm having trouble figuring out where I need to free the malloc'ed code- Here is what I have for both load and unload. Everything else seems to have been freed except for two things, and everything I try to do to free them doesn't work and creates more errors.

[code hidden per academic honesty guidelines]

and here is what I'm getting from Valgrind:

HEAP SUMMARY:
==3458==     in use at exit: 62 bytes in 2 blocks
==3458==   total heap usage: 286,187 allocs, 286,185 frees, 8,873,096 bytes allocated
==3458== 
==3458== Searching for pointers to 2 not-freed blocks
==3458== Checked 78,624 bytes
==3458== 
==3458== 16 bytes in 1 blocks are still reachable in loss record 1 of 2
==3458==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3458==    by 0x40148F: load (dictionary.c:99)
==3458==    by 0x400A7D: main (speller.c:45)
==3458== 
==3458== 46 bytes in 1 blocks are still reachable in loss record 2 of 2
==3458==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3458==    by 0x4014DD: load (dictionary.c:107)
==3458==    by 0x400A7D: main (speller.c:45)
==3458== 
==3458== LEAK SUMMARY:
==3458==    definitely lost: 0 bytes in 0 blocks
==3458==    indirectly lost: 0 bytes in 0 blocks
==3458==      possibly lost: 0 bytes in 0 blocks
==3458==    still reachable: 62 bytes in 2 blocks
==3458==         suppressed: 0 bytes in 0 blocks
==3458== 
==3458== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==3458== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Answer 1

Your issue is here:

while(fgets(line, LENGTH + 1, dic) != NULL)

By definition, char* fgets(char* str, int num, FILE* stream) will read up to num-1 chars or until it reaches a newline or EOF. It then puts those char into str and adds the null terminator.

So, in your case, when you are reading in the dictionary, when you hit the longest word (which is LENGTH chars long), you will read in those LENGTH chars, and they will be stored in line. But the '\n' at the end of that word will not have been read.

Next time around, fgets() will read in that '\n' and store it in the line. Your hash function (based on what you've shown) I'm assuming does some sort of "turn the first letter into a number from 0-25" and line[0] is '\n', which ends up with hash being a number outside of that 0-25 range. But you then create a node for it, and put it into "bad" memory.

Now, when unload() runs, that node is never found, so it never gets freed. So you have 1 node's worth of memory leak.

Be sure your fgets() call reads in enough chars to handle the LENGTH + the newline + the null char.

You might also have noticed that you had 1 more word in your dictionary than you should have (because of that word that was only a newline.)

Answer 2

I've been looking at this one for a while. I can't explain exactly what's happening, but I've found that whenever someone has used this form of strcpy:

newNode->word = strcpy(destination, line);

these problems show up. In looking at online docs, I've seen the return value specified as the address of the destination, the string copied to the destination, or no description at all. I've also found that it is much more reliable to define node->word as a string of length LENGTH+1 instead of a pointer and doing a direct string copy as follows:

strcpy(newNode->word, line);

This puts the word directly in the structure.

I've also found that by doing this in your code, it seems to clean up the memory leak. If anyone else can explain what's happening, I'd like to know too ( @kareem or @curiouskiwi ?) but this may get you past the memory leak.

The most conspicuous thing I've found is that your memory leak is exactly one instance of each of the destination and node mallocs. I still haven't figured out how.

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