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 :-)
XML Feeds