Query about running a program through valgrind and getting false results comparing to other systems

Yesterday i posted this: What's the problem with this code? [hashtable in C] and paxdiablo offered to help me. He posted a sample of code an开发者_如何学编程d asked me to run it through valgrind on my machine. This code normally generates: 12,4 But on my machine, i get 24,8. The doubled! I'm just curious why is that happening. Hope sb has a good explaination.

I post also paxdiablo's code (for anyone who cant find it.)

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

typedef struct HashTable {
    int size ;
    struct List *head;
    struct List *tail;
} HashTable;

typedef struct List {
    char *number;
    char *name;
    int time;
    struct List *next;
} List;

#define size_of_table 211

HashTable *createHashTable(void) {
    HashTable *new_table = malloc(sizeof(*new_table)*size_of_table); //line 606
    printf ("%d\n", sizeof(*new_table));
    printf ("%d\n", sizeof(new_table));
    if (new_table == NULL) {
        return NULL;
    }

    int i=0;
    for(i; i<size_of_table; i++) {
        new_table[i].size=0;
        new_table[i].head=NULL;
        new_table[i].tail=NULL;
    }
    return new_table;
}

int main(void) {
    HashTable *x = createHashTable();
    free (x);
    return 0;
}

Well pointers on your environment are 8 bytes wide, and your ints are also 8 bytes wide by the looks of it. Judging by the error when trying to use -m32 with gcc, I'd hazard a guess that you have the x86_64 version of glibc-devel installed and need to additionally install the x86 (32-bit) version.

Could you post the output from ldd <your_compiled_program>, too? Let us know if this is (not) the case.

You are likely building on a 64-bit platform. 8 byte pointers. If you build it with -m32 it will build as a 32-bit application.

Running your code, I get 24,8 under a 64-bit build and 12,4 under a 32-bit build: MacOS X 10.6.6 (Intel Core 2 Duo), GCC 4.5.2, Valgrind 3.6.0.

32-bit

$ gcc -m32 -g -o vg vg.c
$ valgrind vg
==69827== Memcheck, a memory error detector
==69827== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==69827== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==69827== Command: vg
==69827== 
12
4
==69827== 
==69827== HEAP SUMMARY:
==69827==     in use at exit: 4,416 bytes in 8 blocks
==69827==   total heap usage: 9 allocs, 1 frees, 6,948 bytes allocated
==69827== 
==69827== LEAK SUMMARY:
==69827==    definitely lost: 0 bytes in 0 blocks
==69827==    indirectly lost: 0 bytes in 0 blocks
==69827==      possibly lost: 0 bytes in 0 blocks
==69827==    still reachable: 4,416 bytes in 8 blocks
==69827==         suppressed: 0 bytes in 0 blocks
==69827== Rerun with --leak-check=full to see details of leaked memory
==69827== 
==69827== For counts of detected and suppressed errors, rerun with: -v
==69827== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$

64-bit

$ gcc -m64 -g -o vg vg.c
$ valgrind vg
==69840== Memcheck, a memory error detector
==69840== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==69840== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==69840== Command: vg
==69840== 
24
8
==69840== 
==69840== HEAP SUMMARY:
==69840==     in use at exit: 4,184 bytes in 2 blocks
==69840==   total heap usage: 3 allocs, 1 frees, 9,248 bytes allocated
==69840== 
==69840== LEAK SUMMARY:
==69840==    definitely lost: 0 bytes in 0 blocks
==69840==    indirectly lost: 0 bytes in 0 blocks
==69840==      possibly lost: 0 bytes in 0 blocks
==69840==    still reachable: 4,184 bytes in 2 blocks
==69840==         suppressed: 0 bytes in 0 blocks
==69840== Rerun with --leak-check=full to see details of leaked memory
==69840== 
==69840== For counts of detected and suppressed errors, rerun with: -v
==69840== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$

Of course, valgrind is a red herring; the same results are printed with less verbosity around them without valgrind.