0

Valgrind is telling me that I have 17 allocs and 17 frees; however, it is also telling me that I have 112 bytes in 1 block that are definitely lost. Here is the code from my unload functions:

void freeTrie (node* ptr)
{
    //iterate over the children
    for(int i = 0; i < 27; i++)
    {
        //if found a node inside a child
        if(ptr->children[i] != NULL)
        {
            //call recursively
            freeTrie(ptr->children[i]);
        }
    }
    //free the argument pointer
    free(ptr);
    return;
}

bool unload(void)
{
    //node pointer for the freeing function
    node* curr = root;

    freeTrie(curr);

    //free root and prevnode
    free(root);
    free(prevnode);

    //returns
    if(root == NULL)
    {
        return true;
    }
    else
    {
        return false;
    }
}

As a note, root and prevnode are declared at the top of dictionary.c; however, they are initialized in the load function. I'm well aware there is probably something else going on here. When I run gdb with my code, it doesn't seem to go through the if statement in freeTrie correctly, but I just might be interpreting it wrong.

Does this look like it should be running properly? Are the missing bytes more than likely somewhere else in dictionary.c?

In fact, Valgrind is telling me this:

==5425== 112 bytes in 1 blocks are definitely lost in loss record 1 of 2
==5425==    at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5425==    by 0x8049146: load (dictionary.c:122)
==5425==    by 0x8048725: main (speller.c:46)

The point in load that Valgrind is yelling at me for is where I initialize prevnode with:

prevnode = malloc(sizeof(node));

Oddly, though, it has no problem with the initialization of root which is done the exact same way on the line directly above it. And the line in speller.c main is where load is called.

Thanks in advance!

2

Your code looks mostly good. Although you can return true from your recursive freeTrie() function and then in your unload() function just call freeTrie() on your root node. That's it.

You don't need to worry about anything else because, for example, i expect your curr pointer is not malloc'd on the heap. It's just a node pointer in a function on the stack, so you don't need to free that. Same goes for prevnode. The only things you've likely malloc'd on the heap are the root node and the new nodes, not the marker node pointers.

You can even just directly return the return of your freeTrie function like this:

bool unload(void){
return freeTrie(root);
}

You're also malloc'ing space for a prevnode marker. Which is where valgrind is reporting your missing bytes. If you need that marker you should just be able to do node* prevnode; to create it. That doesn't malloc space on the heap but just creates a normal pointer variable. Then you can set root or currnode or whatever to it and don't need to free it later. You don't need the actual space in bytes of that node.. just a memory address of the other node you want to keep track of. Because what seems to be happening is you're creating that actual space and losing track of it later as you move that marker around.

Hope that helps

Sean

4
  • Thank you very much! Should I be worried about those bytes Valgrind marked as Definitely Lost? – Chris Oct 14 '15 at 12:18
  • I just re-read saw that you're malloc'ing space for a prevnode marker. If you need that marker you should just be able to do node* prevnode; to create it. That doesn't malloc space on the heap but just creates a normal pointer variable. Then you can set root or currnode or whatever to it and don't need to free it later. You don't need the actual space in bytes of that node.. just a memory address of the other node you want to keep track of. Because what seems to be happening is you're creating that actual space and losing track of it later as you move that marker around. – Sean Oct 14 '15 at 14:09
  • If that helps could you vote the answer correct? Thanks! – Sean Oct 14 '15 at 14:26
  • Wow, thank you, that freed up all my memory according to valgrind! This was also linked to a problem in my check() function as well that stumbled my progress in this pset. A seemingly small deletion that takes care of many problems... can someone refer me to a video of someone, say, Mr. Malan or the like, explaining this "heap/stack/memory" business? – Edward Lee Aug 29 '17 at 2:47

You must log in to answer this question.

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