jump to navigation

Server Test Results August 11, 2010

Posted by aknartrebna in Uncategorized.
trackback

Yesterday, on looking at some of the Valgrind output, I discovered that I had a few memory leaks in the code.  I was freeing what I was supposed to, however it was inside an if statement, so I just added an else at the end of each if statement to run mysql_free_result().  So I ran my login/out iterator, and here are the results:

==10813==
==10813== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 48 from 3)
==10813== malloc/free: in use at exit: 86,275 bytes in 25 blocks.
==10813== malloc/free: 39,991,979 allocs, 39,991,954 frees, 119,153,575,663 bytes allocated.
==10813== For counts of detected errors, rerun with: -v
==10813== searching for pointers to 25 not-freed blocks.
==10813== checked 678,324 bytes.
==10813==
==10813==
==10813== 28 bytes in 1 blocks are still reachable in loss record 1 of 3
==10813==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==10813==    by 0x400C355: (within /lib/ld-2.7.so)
==10813==    by 0x4011BA6: (within /lib/ld-2.7.so)
==10813==    by 0x400DA15: (within /lib/ld-2.7.so)
==10813==    by 0x401154D: (within /lib/ld-2.7.so)
==10813==    by 0x4466131: (within /lib/i686/cmov/libc-2.7.so)
==10813==    by 0x400DA15: (within /lib/ld-2.7.so)
==10813==    by 0x44662F4: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.7.so)
==10813==    by 0x44B4DC6: pthread_cancel_init (in /lib/i686/cmov/libpthread-2.7.so)
==10813==    by 0x44B4EF0: _Unwind_ForcedUnwind (in /lib/i686/cmov/libpthread-2.7.so)
==10813==    by 0x44B2900: __pthread_unwind (in /lib/i686/cmov/libpthread-2.7.so)
==10813==    by 0x44ACA1F: pthread_exit (in /lib/i686/cmov/libpthread-2.7.so)
==10813==
==10813==
==10813== 24,927 bytes in 9 blocks are still reachable in loss record 2 of 3
==10813==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==10813==    by 0x40890DC: my_malloc (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4089E2A: my_error_register (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4088D0F: init_client_errs (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40879C8: mysql_server_init (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40AEFF9: mysql_init (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x804A42F: main (bfoc_server.cpp:131)
==10813==
==10813==
==10813== 61,320 bytes in 15 blocks are still reachable in loss record 3 of 3
==10813==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==10813==    by 0x4090142: my_once_alloc (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40907DA: (within /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4091169: (within /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4091486: get_charset_by_csname (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40AEDD1: mysql_init_character_set (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40B0DA2: mysql_real_connect (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x804A473: main (bfoc_server.cpp:134)
==10813==
==10813== LEAK SUMMARY:
==10813==    definitely lost: 0 bytes in 0 blocks.
==10813==      possibly lost: 0 bytes in 0 blocks.
==10813==    still reachable: 86,275 bytes in 25 blocks.
==10813==         suppressed: 0 bytes in 0 blocks.

real    1310m14.214s
user    16m29.950s
sys    5m45.234s

The first memory leak is prolly because instead of exiting the program properly I hit Ctrl+C; the other two are from initializing and connecting to the msyql database — which occurrs in mysql.h. I would fret over this, however it only happens once during the programs running.

25 un-free’d blocks out of almost 40 million allocs/frees is about as good as it gets 🙂  I shouldn’t have to reset the server every day or so now either, nor will I have to worry about it running on only 512MB ram.  Huzzah!

Explanation of memory leaks:  In the C family of languages, you are allowed to access your computer’s memory directly.  So, when you need a non-constant amount of memory for something like a string or a variable amount of data, you have to allocate (or in programmer’s speak, alloc) that amount of memory in order to use with the malloc() function.  When you are done, it has to be freed with the function free().  Un-free’d memory is referred to as a memory leak.  If you get to many, you can potentially run out of memory or at the very minimum take up more space in memory than what is needed, potentially slowing the computer down.  Memory leaks can easily become A Bad Thing.

Advertisements

Comments»

No comments yet — be the first.

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

%d bloggers like this: