Question

I’m using Valgrind version 3.8.0 on OS X 10.8.1, Mountain Lion. Regarding compatibility with 10.8.1, Valgrind’s site says (italics mine):

Valgrind 3.8.0 works on {x86,amd64}-darwin (Mac OS X 10.6 and 10.7, with limited support for 10.8).

I know, then, that there is only “limited support” for 10.8.1. Nonetheless, this bug report says (italics mine):

This (the latest 3.8.0 release) makes Valgrind
compile and able to run small programs on OSX 10.8. Be warned however
that it still asserts with bigger apps, and 32 bit programs are not
checked properly at all (most errors are missed by Memcheck).

Ok, that’s fine. So Valgrind should work, if temperamentally, on 10.8.1. So now my question:

I was able to get Valgrind to compile on 10.8.1 with little trouble, but I saw some weird results when I ran it on a couple small C programs. To try and reduce the possible causes of the issue, I eventually wrote the following “program”:

int main () {                                                               
    return 0;
}

Not very exciting, and little room for bugs, I’d say. Then, I compiled and ran it through Valgrind:

gcc testC.c
valgrind ./a.out

Here’s my output:

==45417== Command: ./a.out
==45417== 
==45417== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==45417== WARNING: Expect incorrect results, assertions and crashes.
==45417== WARNING: In particular, Memcheck on 32-bit programs will fail to
==45417== WARNING: detect any errors associated with heap-allocated data.
==45417== 
--45417-- ./a.out:
--45417-- dSYM directory is missing; consider using --dsymutil=yes
==45417== 
==45417== HEAP SUMMARY:
==45417==     in use at exit: 58,576 bytes in 363 blocks
==45417==   total heap usage: 514 allocs, 151 frees, 62,442 bytes allocated
==45417== 
==45417== LEAK SUMMARY:
==45417==    definitely lost: 8,624 bytes in 14 blocks
==45417==    indirectly lost: 1,168 bytes in 5 blocks
==45417==      possibly lost: 4,925 bytes in 68 blocks
==45417==    still reachable: 43,859 bytes in 276 blocks
==45417==         suppressed: 0 bytes in 0 blocks
==45417== Rerun with --leak-check=full to see details of leaked memory
==45417== 
==45417== For counts of detected and suppressed errors, rerun with: -v
==45417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I know that Valgrind is not ready for prime-time on 10.8.1. Nonetheless, I would love to be able to use it here – I only need to use it on small programs, and nothing is mission-critical about the results being spot-on. But clearly, it is reporting a ton of leaks in a program that seems very unlikely to be leaking. Thus:

What should I do to fix this?

---

Other info:

• Adding an intentionally leaked integer does increment the “definitely lost” count by the appropriate 4 bytes.
• Similarly, intentionally leaking a call to malloc by not freeing the memory does increment the heap alloc count appropriately.
• Compiling with the -g flag and then running to Valgrind (to address the dSYM directory is missing error) does cause that error to disappear, but does not change the issue of tons of memory leaks being reported.

Answer 1

It tells you right there:

Expect incorrect results, assertions and crashes.

If you still want to run it, print detailed information about spurious leaks (--leak-check=full) and use it to suppress messages about them.