Question

I’m running valgrind to look for memory leaks. I have alloc’d two global variables in the main function; then, at the end of main I free both, but Valgrind keeps writing:

==18311== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==18311==    at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==18311==    by 0x804A30C: main (application.c:730)
==18311== 
==18311== 16 bytes in 1 blocks are definitely lost in loss record 2 of 2
==18311==    at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==18311==    by 0x804A31D: main (application.c:731)

Leak summary:

==18311== LEAK SUMMARY:
==18311==    definitely lost: 32 bytes in 2 blocks
==18311==    indirectly lost: 0 bytes in 0 blocks
==18311==      possibly lost: 0 bytes in 0 blocks
==18311==    still reachable: 0 bytes in 0 blocks
==18311==         suppressed: 0 bytes in 0 blocks

Why I can’t free these two variables?

Edit

someList *something; *something_else;

The struct used has two fields of type char * and a field someList *next.
Later there’s a lot of code. A few threads are going to add/edit/delete objects using this two variables.

something -> object 1 -> ... -> object n
something_else -> object 1 -> ... -> object m

Where -> means that something->next = object 1, and object k are all instances of someList *.

Near the end of the application, I freed every field of each object k element. Then, in the last part:

free(something);
free(something_else);

It’s possible that I forgot to free a field of an object. Can this cause the behavior I’m having here?

I hope it’s clearer, now.

Answer 1

For each malloc() call you typically need a corresponding free() call, in order to avoid memory leaks. For optimal memory usage, you should free() each allocated memory block as soon as possible after being done with it.

In your case, you have two malloc() calls in application.c:730 and application.c:731, for which there is no free() call made by the time your program terminates. Therefore, the memory blocks allocated there are not freed. This causes a memory leak that Valgrind detects and reports.

Unless you provide us with some code and/or more information on your program there is no way for us to help you more.

EDIT:

There are two interesting lines in your Valgrind output:

==18311==    definitely lost: 32 bytes in 2 blocks
...
==18311==    still reachable: 0 bytes in 0 blocks

You have definitely “lost” two memory blocks and there no pointers to them at the time your program terminates. This means that the pointers to these two blocks were in fact overwritten or otherwise lost their value during the course of your program.

A common cause of this issue is storing the result of two malloc() calls to the same pointer without an intermediate free() call. Another possible cause is a changed pointer value due to pointer arithmetic operations – Valgrind makes an effort to detect some of these cases, but it is not always successful, depending on your code.