I've been stuck for days in the implementation of LOAD with a TRIE data structure.

I think my code works (well it doesn't show seg faults) but I am getting a lot of memory leaks. I implemented the load function in a separate file load.c, that is what I do when I want to check the operation of a function.

I am using TRIE data structure, Here is my code


But I am getting a lot of memory leaks as you can see here

            ~/workspace/pset5/speller/ $ help50 valgrind --leak-check=full ./load dictionaries/large            ==1758== Memcheck, a memory error detector
        ==1758== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
        ==1758== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
        ==1758== Command: ./load dictionaries/large
        ==1758== HEAP SUMMARY:
        ==1758==     in use at exit: 82,225,920 bytes in 367,080 blocks
        ==1758==   total heap usage: 367,083 allocs, 3 frees, 82,226,936 bytes allocated
        ==1758== 672 bytes in 3 blocks are possibly lost in loss record 1 of 3
        ==1758==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
        ==1758==    by 0x400B21: main (load.c:64)
        ==1758== 82,225,248 (5,824 direct, 82,219,424 indirect) bytes in 26 blocks are definitely lost in loss record 3 of 3
        ==1758==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
        ==1758==    by 0x400A5C: main (load.c:48)
        ==1758== LEAK SUMMARY:
        ==1758==    definitely lost: 5,824 bytes in 26 blocks
        ==1758==    indirectly lost: 82,219,424 bytes in 367,051 blocks
        ==1758==      possibly lost: 672 bytes in 3 blocks
        ==1758==    still reachable: 0 bytes in 0 blocks
        ==1758==         suppressed: 0 bytes in 0 blocks
        ==1758== For counts of detected and suppressed errors, rerun with: -v
        ==1758== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

        Helping with...                                                                                                                               

        ==1758== 82,225,248 (5,824 direct, 82,219,424 indirect) bytes in 26 blocks are definitely lost in loss record 3 of 3
        ==1758==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
        ==1758==    by 0x400A5C: main (load.c:48)

        Looks like your program leaked 82,225,248 bytes of memory. Did you forget to free memory that you allocated via malloc? Take
        a closer look at line 48 of load.c.

By the way, I run my program this way:

            ./load dictionaries/large

1.- How do I free dynamically allocated variable that is been used several times inside a loop? I tried freeing it after every word ends but then I lose the track of it and it guides me to another error.

2.- Is this problem happening because I am implementing load in a separate program?

3.- How can I check visually if my load functions works?

Thank you very much


fclose(open) might cause segfaults if open is NULL. Not best variable name either.

You don't need firstroot if you set branch to root on start of a new word, with that, the first letter is nothing special. You could also reduce duplicate code.

Most importantly: In a load function, you should not free any nodes. The root pointer should be a global variable, and all nodes are still accessible via this pointer. You should free nodes only in unload, or in a function called by unload (for a trie, a recursive unload helper works great).

  • Thanks @Blauelf, but how do I know if I am at the beginning of a word if I don't use a variable telling me that? Because I need to point the first child pointer root->abc[index] just one time. Nov 12 '17 at 21:01
  • Before you enter the for loop is the place where you are about to start a new word or hit EOF. Either way, it's the place to set the cursor (branch) to the root node.
    – Blauelf
    Nov 13 '17 at 0:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .