Valgrind reports leaked memory on OS X 10.8.1

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.

This is outdated. In 2017, Valgrind suppresses most false positives. — Franklin Yu, Jan 09 '17 at 08:45
@FranklinYu Does it suppress most false positives on 10.8.1? If so, write an answer to that effect and I'll mark it accepted. — ravron, Jan 09 '17 at 17:10
@ravron Sorry, no (or at least not that I know). I only tested in 10.11. I was trying to say this issue probably depends on version of OS X. But you may still want to try with latest Valgrind, because they [do suppress *several* (if not *most*) false positives on 10.8](https://github.com/liquid-mirror/valgrind/blob/VALGRIND_3_12_0/darwin12.supp). It used not to suppress any false positives, known from your log `suppressed: 0 bytes in 0 blocks`. So at least it's improved. — Franklin Yu, Jan 10 '17 at 01:13

score 6 · Accepted Answer · answered Sep 17 '12 at 05:09

6

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.

answered Sep 17 '12 at 05:09

n. m. could be an AI

112,515
14
128
243

I was afraid that might be the answer. I'll go ahead and do that. Thanks. – ravron Sep 17 '12 at 11:53

score 6 · Answer 2 · answered Jan 22 '13 at 18:07

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
}

score 0 · Answer 3 · edited May 23 '17 at 12:01

0

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.

edited May 23 '17 at 12:01

Community

1
1

answered Mar 26 '14 at 21:09

Zachary Kraus

1,051
10
21

Valgrind reports leaked memory on OS X 10.8.1

3 Answers3

Linked