Valgrind Saves Time

Coding in C / C++ with all its advantages, brings along with it, its own demons. The big devil whom you will encounter at most times grinning from ear to ear is Memory Management. These can crop up at the most unexpected places and the worst of the bugs are the ones related to heap management which don’t reproduce easily. They might show up sometimes, but at other times the program will run fine. One way is to have an extensive unit testing plan to catch these errors. Another way is to use memory management tools like Valgrind which pinpoint any Invalid writes, memory leaks, dangling pointers etc. It might be a really good practice to valgrind your program as you unit test your code. Consider the example below which was written an year ago minutes before sleep hit me :

buffer [numBytes + 1] = ” /0″;

where buffer is a reference to a std::string .

When the program is run, this is the ouput :

*** glibc detected *** ./talker: double free or corruption (!prev): 0x08122028 ***
======= Backtrace: =========
/lib/libc.so.6[0x43ea68]
/lib/libc.so.6(__libc_free+0x78)[0x441f6f]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x4b27a801]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x4b25738d]
/usr/lib/libstdc++.so.6(_ZNSsD1Ev+0x57)[0x4b259f37]
./talker[0x804917e]
/lib/libc.so.6(__libc_start_main+0xdc)[0x3f04e4]
./talker(__gxx_personality_v0+0x6d)[0x8048de1]
======= Memory map: ========
003be000-003d7000 r-xp 00000000 fd:00 16416968 /lib/ld-2.4.so
003d7000-003d8000 r–p 00018000 fd:00 16416968 /lib/ld-2.4.so
003d8000-003d9000 rw-p 00019000 fd:00 16416968 /lib/ld-2.4.so
003db000-00508000 r-xp 00000000 fd:00 16416979 /lib/libc-2.4.so
00508000-0050a000 r–p 0012d000 fd:00 16416979 /lib/libc-2.4.so
0050a000-0050b000 rw-p 0012f000 fd:00 16416979 /lib/libc-2.4.so
0050b000-0050e000 rw-p 0050b000 00:00 0
00516000-00539000 r-xp 00000000 fd:00 16419168 /lib/libm-2.4.so
00539000-0053a000 r–p 00022000 fd:00 16419168 /lib/libm-2.4.so
0053a000-0053b000 rw-p 00023000 fd:00 16419168 /lib/libm-2.4.so
00841000-00842000 r-xp 00841000 00:00 0 [vdso]
….
b7f11000-b7f13000 rw-p b7f11000 00:00 0
b7f28000-b7f2a000 rw-p b7f28000 00:00 0
bfbea000-bfbff000 rw-p bfbea000 00:00 0 [stack]

Aborted

Now running the program through gdb shortens the circle of concern to the destructor of the class in which buffer is defined. Still its quite difficult to pinpoint what could be the error which is compounded by the fact that its being managed by the standard template library. Now knowing that its a heap memory management fault, its a good idea to run the program through valgrind.

valgrind –tool=memcheck -v ./talker earth /proc/diskstats

Valgrind points out the error right away telling

==9056== 1 errors in context 1 of 1:
==9056== Invalid write of size 1
==9056== at 0x40222E6: UdpSocket::recvFromSocket(std::string&, sockaddr_in) (UdpSocket.cpp:45)

I am still not sure what the bug is , but commenting out

// buffer [numBytes + 1] = ” /0″ ;

makes the program just fine. It might have something to do with stl allocating memory to a string using reserve but i am not sure. Anyways, Valgrind rescued me here. So go ahead and give it a peek 🙂 .

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s