Valgrind reports leaked memory on OS X 10.8.1 - c

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.

Answer 2

Valgrind trunk seems to have improved to the point where it is usable now. I haven't see it crash yet, but do have lots of false positives, which can be dealt with using a suppression file.
Right now, my suppression file looks like this:
# OS X 10.8 isn't supported, has a bunch of 'leaks' in the loader
{
osx_1080_loader_false_positive_1
Memcheck:Leak
...
fun:_ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
...
}
{
osx_1080_loader_false_positive_2
Memcheck:Leak
...
fun:_ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
...
}
{
osx_1080_loader_false_positive_3
Memcheck:Leak
...
fun:map_images_nolock
...
}
{
osx_1080_loader_false_positive_4
Memcheck:Leak
...
fun:_objc_fetch_pthread_data
fun:_ZL27_fetchInitializingClassLista
fun:_class_initialize
fun:_class_initialize
fun:_class_initialize
fun:_class_initialize
fun:prepareForMethodLookup
fun:lookUpMethod
fun:objc_msgSend
fun:_libxpc_initializer
fun:libSystem_initializer
}

Answer 3

I am also running valgrind from macports on mac osx 10.8. It runs without crashing but does produce some crazy results like the ones in this stackoverflow post, Confusing output from Valgrind shows indirectly lost memory leaks but no definitely lost or possibly lost.