10

I have a problem with "extra" memory leaks in valgrind. For example, I created a test program, called temp.cpp:

int main() { return 0; }

In the terminal, I run:

>> g++ -o temp.out temp.cpp
>> valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./temp.out

This results in several memory leaks. How could this be?

==4438== LEAK SUMMARY:
==4438==    definitely lost: 4,120 bytes in 2 blocks
==4438==    indirectly lost: 2,288 bytes in 6 blocks
==4438==      possibly lost: 8,336 bytes in 99 blocks
==4438==    still reachable: 6,440 bytes in 13 blocks  
==4438==         suppressed: 5,020 bytes in 73 blocks

I have tried running other .cpp files and I get the exact same leak summary. About a month ago when I tried, nothing was wrong. I might have upgraded Xcode or something, if that could be the issue (?). These are my settings for g++:

Configured with: 

--prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1

Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin15.0.0 Thread model: posix

Devolus
  • 21,661
  • 13
  • 66
  • 113
Myone
  • 1,103
  • 2
  • 11
  • 24
  • FWIW, I don't observe that on Linux/Debian/x86-64 with GCC 5.2; the three "lost" lines from `valgrind` gives me 0; and likewise with Clang 3.7; it might be a MacOSX specific issue – Basile Starynkevitch Nov 11 '15 at 19:54
  • 1
    It sounds like you should file a bug report with the valgrind folks. I'm not sure exactly how you expect stackoverflow to help you. – xaxxon Nov 25 '15 at 10:36
  • sometime third party libs create leaks you cannot fix (unless you fix the lib). They are reported by valgrind, but you can suppress them using sup file in valgrind. For some reason, maybe you libc leaks or the loader... having the full backtrace would be interesting. – OznOg Dec 04 '15 at 09:11

2 Answers2

2

It seems valgrind have issues on MacOSX. While these issues are not fixed, a possible temporary solution would be the use of a suppression file. For further details, please check this other answer

Community
  • 1
  • 1
Vinicius
  • 21
  • 2
0

I tried to reproduce this but I couldn't on my machine. It seems that there is no leak on the newest valgrind. Try brew upgrade valgrind

C02QH2D7G8WM:simple userone$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./temp.out
==1917== Memcheck, a memory error detector
==1917== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1917== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1917== Command: ./temp.out
==1917== 
==1917== 
==1917== HEAP SUMMARY:
==1917==     in use at exit: 22,177 bytes in 189 blocks
==1917==   total heap usage: 255 allocs, 66 frees, 27,953 bytes allocated
==1917== 
==1917== 2,064 bytes in 1 blocks are possibly lost in loss record 57 of 62
==1917==    at 0x10000817C: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==1917==    by 0x1005E0EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D4182: protocols() (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D4093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D1C13: gc_init (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D924E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005E6132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D483C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D4300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D42E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D42E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917==    by 0x1005D42E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==1917== 
==1917== LEAK SUMMARY:
==1917==    definitely lost: 0 bytes in 0 blocks
==1917==    indirectly lost: 0 bytes in 0 blocks
==1917==      possibly lost: 2,064 bytes in 1 blocks
==1917==    still reachable: 0 bytes in 0 blocks
==1917==         suppressed: 20,113 bytes in 188 blocks
==1917== 
==1917== For counts of detected and suppressed errors, rerun with: -v
==1917== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 17)
Dendi Suhubdy
  • 2,877
  • 3
  • 19
  • 20