Fixing my first memory leak (yay!)
I really want to dig more into C programming and get good at it. I think it’s the way I can take my coding skills to the next level. Or down a level depending on how you look at it. So I was doing research and pondering what I can do for a next project and trying to better understand memory management in C because other languages I’ve used don’t have this factor to them. Knowing this I found a program called valgrind that allows you to run a program compiled with debugging and it will check if you have any memory issues.
Installation was easy, it’s in the arch official repositories. The manual on the website is easy to follow and get started. First compile with -g to get debugging info, then run the program with –leak-check=yes.
It opened up the calendar and I moved around a few months the exited. Here’s what I got first time:
➜ calendar git:(main) ✗ valgrind --leak-check=yes calendar
==1908043== Memcheck, a memory error detector
==1908043== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1908043== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1908043== Command: calendar
==1908043==
==1908043==
==1908043== HEAP SUMMARY:
==1908043== in use at exit: 240 bytes in 15 blocks
==1908043== total heap usage: 333 allocs, 318 frees, 159,212 bytes allocated
==1908043==
==1908043== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==1908043== at 0x483E77F: malloc (vg_replace_malloc.c:307)
==1908043== by 0x1094EF: cal (in /usr/local/bin/calendar)
==1908043== by 0x109DA3: main (in /usr/local/bin/calendar)
==1908043==
==1908043== 224 bytes in 14 blocks are definitely lost in loss record 2 of 2
==1908043== at 0x483E77F: malloc (vg_replace_malloc.c:307)
==1908043== by 0x1094EF: cal (in /usr/local/bin/calendar)
==1908043== by 0x1097A9: keypress (in /usr/local/bin/calendar)
==1908043== by 0x109DC6: main (in /usr/local/bin/calendar)
==1908043==
==1908043== LEAK SUMMARY:
==1908043== definitely lost: 240 bytes in 15 blocks
==1908043== indirectly lost: 0 bytes in 0 blocks
==1908043== possibly lost: 0 bytes in 0 blocks
==1908043== still reachable: 0 bytes in 0 blocks
==1908043== suppressed: 0 bytes in 0 blocks
==1908043==
==1908043== For lists of detected and suppressed errors, rerun with: -s
==1908043== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
“definitely lost”: your program is leaking memory – fix it!
Well can’t say I’m surprised. Time to track it down.
I checked for any malloc statements and only found one. Where I create a buffer to hold the calculated cal command. I did not free that memory afterward. So adding a free statement fixed that and now:
➜ calendar git:(main) ✗ valgrind --leak-check=yes ./calendar
==1932539== Memcheck, a memory error detector
==1932539== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1932539== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1932539== Command: ./calendar
==1932539==
==1932539==
==1932539== HEAP SUMMARY:
==1932539== in use at exit: 0 bytes in 0 blocks
==1932539== total heap usage: 238 allocs, 238 frees, 124,817 bytes allocated
==1932539==
==1932539== All heap blocks were freed -- no leaks are possible
==1932539==
==1932539== For lists of detected and suppressed errors, rerun with: -s
==1932539== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
This little article is essentially showing how I learn. I screw up and then I learn how and why I did it. That process of fixing my mistakes is my learning process, if there aren’t any mistakes, I haven’t learned anything.
Next time I allocate some memory (hopefully) I’ll remember this and free when I’m done.
If you are interested the code is over on my github
Tags: tech