Archives for: December 2005, 03

12/03/05

More valgrind abuse

After my previous article on Valgrind I started using it more and more, and discovered another nice feature of it. Just check this sample:

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

#define MESSAGE "test"

int main(int argc, char *argv[]) {
        char *t = NULL;

        /* Hey, everyone makes mistakes */
        t = (char *)malloc(strlen("" MESSAGE) * sizeof(char));
        assert(t != NULL);
        strcpy(t, "" MESSAGE);

        printf("%s\n", t);

        free(t);

        return 0;
}

Compiling and running looks ok:

$ gcc -g -Wall -Werror -o test2 test2.c
$ ./test2
test

But luckily there's Valgrind to tell us the code is horribly wrong:

$ valgrind --tool=memcheck ./test2
==13483== Memcheck, a memory error detector for x86-linux.
==13483== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==13483== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==13483== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==13483== For more details, rerun with: -v
==13483==
==13483== Invalid write of size 1
==13483==    at 0x1B906485: strcpy (mac_replace_strmem.c:199)
==13483==    by 0x80484B2: main (test2.c:14)
==13483==  Address 0x1BA5C02C is 0 bytes after a block of size 4 alloc'd
==13483==    at 0x1B906B82: malloc (vg_replace_malloc.c:131)
==13483==    by 0x8048472: main (test2.c:12)
==13483==
==13483== Invalid read of size 1
==13483==    at 0x1B968B6B: _IO_vfprintf (in /lib/tls/libc-2.3.5.so)
==13483==    by 0x1B96DF36: _IO_printf (in /lib/tls/libc-2.3.5.so)
==13483==    by 0x1B93DF36: __libc_start_main (in /lib/tls/libc-2.3.5.so)
==13483==  Address 0x1BA5C02C is 0 bytes after a block of size 4 alloc'd
==13483==    at 0x1B906B82: malloc (vg_replace_malloc.c:131)
==13483==    by 0x8048472: main (test2.c:12)
test
==13483==
==13483== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1)
==13483== malloc/free: in use at exit: 0 bytes in 0 blocks.
==13483== malloc/free: 1 allocs, 1 frees, 4 bytes allocated.
==13483== For a detailed leak analysis,  rerun with: --leak-check=yes
==13483== For counts of detected errors, rerun with: -v

This should be fairly self-explaining... I guess most C programmers forgot to allocate strlen(msg)+1 (the end '\0') at least once in their life...

By the way: hello Planet Grep :-)

Permalink . Ikke . 11:29:18 pm . 357 Words . Coding Corner . . 380 views . 5 comments