Valgrind claims there is unfreed memory. Is this bad?

Valgrind giv开发者_如何学Ces me the following leak summary on my code. However, I have freed all malloc'ed memory. Is this a bad thing, or is this normal? My program is in c.

==3513== LEAK SUMMARY:

==3513== definitely lost: 0 bytes in 0 blocks.

==3513== possibly lost: 0 bytes in 0 blocks.

==3513== still reachable: 568 bytes in 1 blocks.

==3513== suppressed: 0 bytes in 0 blocks.

---

The valgrind message still reachable: 568 bytes in 1 blocks. means that there was memory freed in your application which is still "reachable", which means that you still have a pointer to it somewhere. At shutdown, this probably means a global variable of some kind. However, since the number of bytes "definitely leaked" or "probably leaked" is zero, this condition is completely benign. Don't worry about it.

---

Still reachable memory means that it is being pointed to by a global or static pointer. What you want to do is run valgrind with --show-reachable=yes to see whether it's a problem.

Often times it's harmless and comes from a function like this:

void foo()
{
    static char *buffer = 0;
    if (buffer == 0)
    {
        buffer = (char *)malloc(...);
    }
}

That malloc will still be reachable. But no matter how many times foo is called, you allocate the buffer exactly once so there is no harm here in not freeing it.

But consider a function like this:

void foo()
{
    static node_t *head = 0;

    node_t *node = (node_t *)malloc(sizeof(node_t));
    if (node)
    {
        node->next = head;
        head = node;
    }
    ...
}

Every time this function is called, another node will be allocated. While you may only leak a few nodes for your test runs, in a production run, you could leak enough that you run out of memory.

One way to tell the difference is to see if different runs always leak the same memory or you leak more memory are test runs with larger inputs.

But again, if you want to be safe, use --show-reachable=yes and see what's happening.

---

These are not leaked and nothing to be concerned about. The memory was probably allocated by the C library. If you really want to know where they were allocated run with --leak-check=full --show-reachable=yes.

---

If you are sure that you "have freed all malloc'ed memory", then, no there's nothing wrong. You are not directly responsible for memory leaks in components from other parties even though you may often have to work around them.

The reports from valgrind don't really give enough information for us to help you out.

I've seen memory checking tools come up with false positives many times but I don't have any direct experience with valgrind itself.

---

Does it give you the address of the block? sometimes you can learn a lot by looking at what sort of data is in those 568 bytes.

Hmm, 568 bytes, that's about the size of a MAX_PATH unicode string.

---

It would be a good idea to zero out pointers that were free()'ed, which would cause a crash upon (incorrectly) trying to dereference them again.

---

Personally, I always keep forgetting and checking like valgrind make test which always adds at least couple of additional still reachable bytes... Make sure that Your application is being ran directly by valgrind... :)