as the dust settles on the enrollment rush at school and people are getting prept for another week of add/drop slot fight, i treated myself to a hearty bowl of maggi and started doing some hermetic studies i realized, i should have done years ago.
yesterday, i finally understood the meaning of the terminologies “trunk”, “branch” and “tag”. used in source code management systems like cvs and svn to name a few. (don’t know if the same ideas apply to git though) anyway, i kept documents and source codes in cvs once. but i used cvs only superficially. to me, it was just a means of keeping files in an orderly fashion, in a central location. not to track changes and do other _important_ stuffs like generating diffs from different revisions. i missed out on it’s true purpose… but i know that was mental inadequacy on my part. mental inadequacy is something i can’t get rid of. trying out svn as of this time of writing.
oh well, on other past thoughts….
a few days ago, i asked a friend in a sort of trivialistic fashion, “what would happen if we free() an already de-allocated memory block?” my gut told me that’s something bad… but we both can’t put our finger on what really happens . so i planned a little experiment to satisy my soul.
today, i wrote a small program that malloc()s an int and free()s it afterwards, to find out answers and not just rely on some texts or someone explaining this or that. i compiled the program then ran it through valgrind.
foo.c
#include <stdlib.h>
int main ()
{
int *pt;
pt = malloc (sizeof(int));
if (pt == NULL) {
printf (”memory request failed.\n”);
return 1;
}
free (pt);
return 0;
}
below is the output. lines of importance are in bold.
amerei@heaven ~ $ valgrind --tool=memcheck --leak-check=yes foo
==12323== Memcheck, a memory error detector for x86-linux.
==12323== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==12323== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==12323== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==12323== For more details, rerun with: -v
==12323==
==12323==
==12323== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 1)
==12323== malloc/free: in use at exit: 0 bytes in 0 blocks.
==12323== malloc/free: 1 allocs, 1 frees, 4 bytes allocated.
==12323== For counts of detected errors, rerun with: -v
==12323== No malloc’d blocks — no leaks are possible.
ok. so the program runs cool. now what if i free() two times? valgrind tells me..
amerei@heaven ~ $ valgrind --tool=memcheck --leak-check=yes foo
==12364== Memcheck, a memory error detector for x86-linux.
==12364== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==12364== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==12364== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==12364== For more details, rerun with: -v
==12364==
==12364== Invalid free() / delete / delete[]
==12364== at 0x1B90298D: free (vg_replace_malloc.c:153)
==12364== by 0x804842A: main (in /home/amerei/foo)
==12364== Address 0x1B906028 is 0 bytes inside a block of size 4 free’d
==12364== at 0x1B90298D: free (vg_replace_malloc.c:153)
==12364== by 0x804841F: main (in /home/amerei/foo)
==12364==
==12364== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 10 from 1)
==12364== malloc/free: in use at exit: 0 bytes in 0 blocks.
==12364== malloc/free: 1 allocs, 2 frees, 4 bytes allocated.
==12364== For counts of detected errors, rerun with: -v
==12364== No malloc’d blocks — no leaks are possible.
i kinda got carried away so i tried something else … “what happens if i don’t free()?” again, i humble myself before the almighty valgrind.
amerei@heaven ~ $ valgrind --tool=memcheck --leak-check=yes foo
==12411== Memcheck, a memory error detector for x86-linux.
==12411== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==12411== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==12411== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==12411== For more details, rerun with: -v
==12411==
==12411==
==12411== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 1)
==12411== malloc/free: in use at exit: 4 bytes in 1 blocks.
==12411== malloc/free: 1 allocs, 0 frees, 4 bytes allocated.
==12411== For counts of detected errors, rerun with: -v
==12411== searching for pointers to 1 not-freed blocks.
==12411== checked 1264544 bytes.
==12411==
==12411== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12411== at 0x1B90236C: malloc (vg_replace_malloc.c:131)
==12411== by 0x80483CF: main (in /home/amerei/foo)
==12411==
==12411== LEAK SUMMARY:
==12411== definitely lost: 4 bytes in 1 blocks.
==12411== possibly lost: 0 bytes in 0 blocks.
==12411== still reachable: 0 bytes in 0 blocks.
==12411== suppressed: 0 bytes in 0 blocks.
==12411== Reachable blocks (those to which a pointer was found) are not shown.
==12411== To see them, rerun with: –show-reachable=yes
memory leak. nuff said.
conclusions:
having studied c++ for my first and second years in ateneo, i came to the realization that some of the thoughts i’ve made about programming are conditioned to a some extent. (i switched to c immediately though) common sense told me that i must have a matching free() for every malloc() i call, no more no less. but then if i haven’t done this little experiment, i wouldn’t have known the reason behind the malloc()-free() pairs. staring at other people’s code e.g. /usr/src/linux has given me insights i could never have learned at school. there are still lots to be learned. and hopefully, if i remain perseverant, i would eventually talk c as good as these people one day. some, if not all give terrible, insulting comments, you’d almost feel like committing suicide. but then girls do to, and i’m still alive. i guess i’ll go study more about valgrind now. never a dull day with gentoo.
lastly, miss che is so cute!!!