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

1 Answer 1


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, 2017 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, 2017 at 0:03

You must log in to answer this question.

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