How declaring a variable with malloc lead to lost bits?

Question

First, I have ran valgrind to make sure that (on the default settings) there are zero errors. Then, I decided to check for leaks with something like: --leak-check=full

I have code that looks something like char* variable=malloc(sizeof(char)*(strlen(in)+1)); and valgrind reports that memory is "definitely lost."

The only other line of code I have access to (this is in a library callback function) is the line of code where in is declared. This is a function argument of type void * (though in this case I'm hoping we can safely assume the value to be null terminated.)

Since you haven't provided entire code, I cannot be accurate but it is possible you are not freeing up "variable" anywhere. Also, does https://stackoverflow.com/questions/31061326/why-valgrind-report-my-memory-as-definitely-lost help in understanding your problem? — Kishan Parekh, Feb 17 '19 at 15:04
Annnnnnd of course. I KNEW that that is how malloc works. In fact I was counting on it elsewhere.. thanks a lot, guys! — user1833028, Feb 17 '19 at 15:35

score 2 · Accepted Answer · answered Feb 17 '19 at 15:09

Having

#include <stdlib.h>

char * G;

int main()
{
   char * l = malloc(10);

   G = malloc(20);
}

The execution under valgrind gives :

pi@raspberrypi:/tmp $ valgrind --leak-check=full ./a.out
==11087== Memcheck, a memory error detector
==11087== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11087== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11087== Command: ./a.out
==11087== 
==11087== 
==11087== HEAP SUMMARY:
==11087==     in use at exit: 30 bytes in 2 blocks
==11087==   total heap usage: 2 allocs, 0 frees, 30 bytes allocated
==11087== 
==11087== 10 bytes in 1 blocks are definitely lost in loss record 1 of 2
==11087==    at 0x4847568: malloc (vg_replace_malloc.c:299)
==11087==    by 0x10453: main (mm.c:7)
==11087== 
==11087== LEAK SUMMARY:
==11087==    definitely lost: 10 bytes in 1 blocks
==11087==    indirectly lost: 0 bytes in 0 blocks
==11087==      possibly lost: 0 bytes in 0 blocks
==11087==    still reachable: 20 bytes in 1 blocks
==11087==         suppressed: 0 bytes in 0 blocks
==11087== Reachable blocks (those to which a pointer was found) are not shown.
==11087== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11087== 
==11087== For counts of detected and suppressed errors, rerun with: -v
==11087== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 3)

The malloc(10) is definitely lost because there is no way to access it at the end of the execution (here out of main)

The malloc(20) is not lost because still reachable through G

Whoah, lemme check before I accept your answer, I think that's it! — user1833028, Feb 17 '19 at 15:15
@user1833028 trust on _valgrind_, if it says _definitely lost_ that means there are ;-) — bruno, Feb 17 '19 at 15:24
@user1833028 I cannot produce that case in a normal code (look at http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks), but for "indirectly lost" replace my code about _l_ by `char ** l = malloc(2*sizeof(char *)); /* definitively lost */` and `*l = malloc(10); /* indirectly lost */` — bruno, Feb 17 '19 at 15:57

How declaring a variable with malloc lead to lost bits?

1 Answers1