How does valgrind calculate my example memory leak?

Question

I have purposefully remove the deallocation of structures and would like to learn how valgrind calculates the memory leak.

#include <stdio.h>
#include <assert.h>
#include <stdlib.h>
#include <string.h>

struct Person{
    char *name;
    int age;
    int height;
    int weight;
};

struct Person *Person_create(char *name, int age, int height, int weight){
    struct Person *who = malloc(sizeof(struct Person));
    assert(who != NULL);

    who->name = strdup(name);
    who->age = age;
    who->height = height;
    who->weight = weight;

    return who;
}

void Person_destroy(struct Person *who){
    assert(who != NULL);
    free(who->name);
    free(who);
}

void Person_print(struct Person *who){
    printf("Name: %s\n", who->name);
    printf("\tAge: %d\n", who->age);
    printf("\tHeight: %d\n", who->height);
    printf("\tWeight: %d\n", who->weight);
}

int main(int argc, char *argv[]){
    //make two people structures
    struct Person *joe = Person_create("Joe Alex", 32, 64, 140);
    struct Person *frank = Person_create("Frank Blank", 20, 72, 180);

    //print them out and where they are in memory
    printf("Joe is at memory location %p\n", joe);
    Person_print(joe);

    printf("Frank is at memory location %p\n", frank);
    Person_print(frank);

    //make everyone age 20 years and print them again
    joe->age += 20;
    joe->height -= 2;
    joe->weight += 40;
    Person_print(joe);

    frank->age += 20;
    frank->weight += 20;
    Person_print(frank);

//  Person_destroy(joe);
//  Person_destroy(frank);

    return 0;
}

Valgrind output:

==7687== HEAP SUMMARY:
==7687==     in use at exit: 69 bytes in 4 blocks
==7687==   total heap usage: 4 allocs, 0 frees, 69 bytes allocated
==7687== 
==7687== 33 (24 direct, 9 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 4
==7687==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7687==    by 0x40067B: Person_create (ex16.c:14)
==7687==    by 0x4007B9: main (ex16.c:40)
==7687== 
==7687== 36 (24 direct, 12 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
==7687==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7687==    by 0x40067B: Person_create (ex16.c:14)
==7687==    by 0x4007D6: main (ex16.c:41)
==7687== 
==7687== LEAK SUMMARY:
==7687==    definitely lost: 48 bytes in 2 blocks
==7687==    indirectly lost: 21 bytes in 2 blocks
==7687==      possibly lost: 0 bytes in 0 blocks
==7687==    still reachable: 0 bytes in 0 blocks
==7687==         suppressed: 0 bytes in 0 blocks
==7687== 
==7687== For counts of detected and suppressed errors, rerun with: -v
==7687== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

If I dont free two struct I create, the leak should be 4*4*2 = 32 bytes. Why is the total number of bytes leak 48?

Platform info from uname -a: Linux mymachine 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

score 4 · Accepted Answer · edited May 23 '17 at 11:57

4

You are compiling for a 64-bit platform with 32-bit ints, and the struct is getting laid out as follows:

char *name;  /* 8 bytes */
int age;     /* 4 bytes */
int height;  /* 4 bytes */
int weight;  /* 4 bytes */
             /* 4 bytes of padding to make it possible to create */
             /*   correctly-aligned arrays of struct Person      */

Thus sizeof(struct Person) is 24 and not 16 as you're assuming. Two of those make 48 bytes.

For a discussion of padding and alignment, see Why isn't sizeof for a struct equal to the sum of sizeof of each member?

edited May 23 '17 at 11:57

Community

1
1

answered Dec 21 '14 at 20:01

NPE

486,780
108
951
1,012

Thanks for the reminder. I specified it in the update. – drdot Dec 21 '14 at 20:04
@dannycrane: Then the pointer is definitely 64 bits wide, and there's padding at the end of the struct. See the updated answer. – NPE Dec 21 '14 at 20:07
why is the padding at the end necessary? – drdot Dec 21 '14 at 21:42
@dannycrane The selected answer of the following link provides a good answer to your question. http://stackoverflow.com/questions/119123/why-isnt-sizeof-for-a-struct-equal-to-the-sum-of-sizeof-of-each-member – yeyo Dec 21 '14 at 22:06

score 0 · Answer 2 · answered Dec 21 '14 at 19:58

0

When you ask for M bytes, the library allocates M+x bytes, where 'x' is the number it needs to keep track. Those might be a header, those might be rounding up the amount of storage to some standard block.

answered Dec 21 '14 at 19:58

bmargulies

97,814
39
186
310

How does valgrind calculate my example memory leak?

2 Answers2