Possible Memory Leak Valgrind in OSX El Capitan

Question

I'm getting a warning for possibly lost: 2,064 bytes in 1 blocks when using Valgrind on OSX Yosemite. Is there a fix to this? I installed valgrind using brew.

Below is an example of how to reproduce

~/cat hello.c
int main() {
    return 123;
}

~/uname -a
Darwin mac.local 15.2.0 Darwin Kernel Version 15.2.0: Fri Nov 13 19:56:56 PST 2015; root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64 i386 MacBookAir6,2 Darwin

~/clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix

~/valgrind --version
  valgrind-3.11.0

~/brew info valgrind
valgrind: stable 3.11.0 (bottled), HEAD
Dynamic analysis tools (memory, debug, profiling)
http://www.valgrind.org/
/usr/local/Cellar/valgrind/3.11.0 (328 files, 46.7M) *
  Poured from bottle
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/valgrind.rb

~/clang hello.c -o hello.o

~/valgrind --leak-check=full ./hello.o
==7972== Memcheck, a memory error detector
==7972== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7972== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7972== Command: ./hello.o
==7972== 
==7972== 
==7972== HEAP SUMMARY:
==7972==     in use at exit: 22,411 bytes in 187 blocks
==7972==   total heap usage: 271 allocs, 84 frees, 28,651 bytes allocated
==7972== 
==7972== 2,064 bytes in 1 blocks are possibly lost in loss record 57 of 62
==7972==    at 0x10000817C: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==7972==    by 0x1004F3EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7182: protocols() (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E4C13: gc_init (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004EC24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004F9132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E783C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972== 
==7972== LEAK SUMMARY:
==7972==    definitely lost: 0 bytes in 0 blocks
==7972==    indirectly lost: 0 bytes in 0 blocks
==7972==      possibly lost: 2,064 bytes in 1 blocks
==7972==    still reachable: 0 bytes in 0 blocks
==7972==         suppressed: 20,347 bytes in 186 blocks
==7972== 
==7972== For counts of detected and suppressed errors, rerun with: -v
==7972== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 17)

If you wouldn't mind either marking my answer correct or posting your solution if it was different, I'd appreciate it :) — Ben Lindsay, Jul 31 '16 at 18:50
Tbh I haven't touched Valgrind or c for months so I don't have an informed opinion about what's correct. What's SO protocol in this situation? — Idr, Jul 31 '16 at 18:52
Not sure. I guess if you're still figuring out how to resolve your issue or if you plan to try resolving some time in the future, then leave it until you find that someone's answer was helpful or just post your own answer. If you just kind of abandoned the problem altogether and don't plan to come back to it, then I figure you might as well choose an answer to close it out. You can always change the answer later if a better one comes out — Ben Lindsay, Aug 01 '16 at 02:45

score 16 · Accepted Answer · edited May 23 '17 at 12:26

Valgrind is mostly a tool for Linux, and is less supported for OSX. This means that Valgrind will generate a lot of false positives on OSX. If you want to suppress those possibly lost leaks, then add the --gen-suppressions=all (or --gen-suppressions=yes if you want to pick and choose reported leaks one by one) option to your valgrind call. What this will do is print off a chunk of text for each reported memory leak that will look something like this:

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: indirect
   fun:malloc
   fun:__Balloc_D2A
   fun:__rv_alloc_D2A
   fun:__dtoa
   fun:__vfprintf
   fun:__v2printf
   fun:vfprintf_l
   fun:printf
   fun:main
}

Copy and paste that, brackets and all, to a file called something like /Users/username/leak1.supp. Feel free to change the <...> to an actual name for your suppression. Then when you call valgrind, if you add a --suppressions=/Users/<username>/leak1.supp option, that memory leak report will be suppressed. To make this easier, you can just put stuff in a ~/.valgrindrc file. This file could look something like

--tool=memcheck
--leak-check=full
--show-reachable=yes
--suppressions=/Users/benlindsay/leak1.supp
--suppressions=/Users/benlindsay/leak2.supp

Or if you can just test your code on a Linux machine instead, you won't have to worry about all this ;)

--EDIT--

I got a lot of my info from this other SO post

In general I don't know how you'd tell if you're seeing a false positive or not, but in your specific case, you're not allocating any memory, so it's pretty reasonable to assume that you aren't leaking any memory. — Ben Lindsay, Aug 01 '16 at 02:29
just looked at the output again and I see swift stuff. Weird!? — Idr, Aug 01 '16 at 02:41
Yeah, I guess some of the false positives in Mac OSX have to do with the bootstrapped C libraries (see [this answer](http://stackoverflow.com/a/8657357/2680824) to another post), which might explain that... — Ben Lindsay, Aug 01 '16 at 02:51

Possible Memory Leak Valgrind in OSX El Capitan

1 Answers1

Linked