Valgrind for Mac OS X – first impressions

Not so long ago, Apple developer Greg Parker, published a patch for a specific revision of Valgrind so that it can work in Mac OS X. You can check the details of how to install it in his webpage, it doesn’t take more than 5 minutes to do it:

• http://www.sealiesoftware.com/valgrind

I made a simple test to see how well or bad it works, with definitely lost and still reachable memory leaks. The test goes as follows:

#include <stdio.h>
#include <string.h>
/* Global string, still-reachable */
static char *global_str;
int main(int argc, char **argv)
{
  /* Function-local string,
   * definitely-lost */
  char *str = NULL;
  /* These are 10+1 bytes leaked */
  str = strdup("1234567890");
  /* These are 15+1 bytes leaked */
  global_str = strdup("123456789012345");
  return 0;
}


We compile it…

$> gcc -o test test.c


Now, let’s see if this valgrind port catches our memory leaks.

$> valgrind --show-reachable=yes --leak-check=full --leak-resolution=high ./test


Well, valgrind runs and we start checking its output:

==13340== LEAK SUMMARY:
==13340== definitely lost: 11 bytes in 1 blocks.
==13340== possibly lost: 0 bytes in 0 blocks.
==13340== still reachable: 316 bytes in 8 blocks.
==13340== suppressed: 0 bytes in 0 blocks.


We were only expecting 11 bytes definitely lost (local-function pointer) and 16 bytes still reachable (global pointer), but we have lots more still reachable. Let’s see the detailed results:

==13340== ERROR
==13340== 11 bytes in 1 blocks are definitely lost in loss record 1 of 4
==13340== at 0x22E53: malloc+99 (in /usr/local/lib/valgrind/x86-darwin/vgpreload_memcheck.so)
==13340== by 0x21A3D1: strdup+33 (in /usr/lib/libSystem.B.dylib)
==13340== by 0x1FBB: main+33 (in ./test)
==13340==
==13340== ERROR
==13340== 16 bytes in 1 blocks are still reachable in loss record 2 of 4
==13340== at 0x22E53: malloc+99 (in /usr/local/lib/valgrind/x86-darwin/vgpreload_memcheck.so)
==13340== by 0x21A3D1: strdup+33 (in /usr/lib/libSystem.B.dylib)
==13340== by 0x1FCC: main+50 (in ./test)


Ok, here are our memory leaks. Let’s see what is the other stuff.

==13340== ERROR
==13340== 60 bytes in 1 blocks are still reachable in loss record 3 of 4
==13340== at 0x22E53: malloc+99 (in /usr/local/lib/valgrind/x86-darwin/vgpreload_memcheck.so)
==13340== by 0x1F7E89: get_or_create_key_element+157 (in /usr/lib/libSystem.B.dylib)
==13340== by 0x1F7DBB: _keymgr_get_and_lock_processwide_ptr_2+21 (in /usr/lib/libSystem.B.dylib)
(.....)
==13340== ERROR
==13340== 240 bytes in 6 blocks are still reachable in loss record 4 of 4
==13340== at 0x24DD9: calloc+105 (in /usr/local/lib/valgrind/x86-darwin/vgpreload_memcheck.so)
==13340== by 0x1F79D9: dwarf2_unwind_dyld_add_image_hook+40 (in /usr/lib/libSystem.B.dylib)
==13340== by 0x8FE03D61: dyld::registerAddCallback(void (*)(mach_header const*, long))+145 (in /usr/lib/dyld)
(.....)


As expected (Greg already warned about it) we are getting some leak reports of system libraries, as being still reachable. The “still reachable” means that when the program ended some allocations were done previously using pointers that are ‘global’ to the program, so still reachable when program ended. In other words, valgrind found pointers to allocated memory in the context when the program ended, and the only context available in that time is the global one. All the other contexts (different functions called, even main()) dissappear when the program ends, and pointers declared in those functions which are used to allocate memory are the “definitely lost” ones.

Well, I would say that there is still work to be done, but I don’t see having these system library allocation leak reports a real problem. Once you have linked your programs against Glib, you will get used to see this kind of error reports, but multiplied by 1000. Glib does lots of memory allocations in g_type_init() that are not deallocated with a g_type_deinit() (there is no such function), so they are deallocated by the OS when the program ends. To deal with the ones from Glib, it’s usual to skip using
leak-resolution=high and use Valgrind suppression files.

Probably these reported errors are not comparable to the ones from Glib, but the way to deal with them should be really similar. So, good job Greg! and let’s see if this port can be improved until it’s completely included in Valgrind sources.

It’s all about Freedom

I am quite a GNU/Linux fan. I work developing apps for GNU systems, I collaborate with the development of some GNU projects, I mainly use free software applications… but last year I bought a Mac Book Pro. My first impression of Mac OS X was great. It’s really a great operating system, it has a nice terminal, great support for GNU tools (gcc, gdb, autotools…), and multiple free software applications available. But, there’s always a but… the world of free software is full of nice apps, and not all those apps (or an equivalent replacement) are available for Mac OS X.

I already have a dual boot in my Mac Book Pro, with Kubuntu GNU/Linux available in a 15GB partition. When I installed it, it was basically because most of the programs I was using for development were not available in Mac OS X (valgrind, electric fence, meld, those are essential!). Then, I realized that I was going back again to the years when I had a dual boot with Windows XP and GNU/Linux. In those years, I needed Windows XP to play games, and for nothing else. So here I am again in th same situation. But… wait… the question is… why do I need Mac OS X now?

This is the list of programs I normally use which are available in both Mac OS X and GNU/Linux:

• GNU emacs
• GNU compiler collection (gcc)
• GNU debugger (gdb)
• Mozilla Firefox
• Mozilla Thunderbird
• VLC
• GNU image manipulation program (gimp)
• CVS, Subversion & GNU Bazaar
• OpenVPN
• glib

I also use other programs in Mac OS X which have a perfect replacement in GNU/Linux:

• iTunes -> Amarok, which is even better, free software, and doesn’t support DRM [1]
• NetNewsWire (free as in free beer)-> Akregator. An RSS reader, free as in freedom.
• Colloquy -> Konversation. An IRC client.
• Adium -> Kopete. An instant messenger.
• Disk Utility -> K3b. Probably one of the bests CD burning programs.

This is the list of programs I use and which are only available in GNU/Linux:

• Meld
• Valgrind (there seems to be a non-complete port of Valgrind for Mac OS X. Didn’t check it) [2]
• Electric fence
• Yakuake
  

This is the list of programs I use and which are only available in Mac OS X:

• <yes, it’s empty>

This change back to GNU/Linux could be understood as just based on my needs at a given moment, which in part is true, but I also want to use a Free Software operating system, and Free Software programs. At the end, it’s all about Freedom [3].

References

• [1] http://www.defectivebydesign.org
• [2] Valgrind for Mac OS X
• [3] Free Software Fundation