Menu
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)
531
To get the details you need, add --show-leak-kinds=reachable or --show-leak-kinds=all to the Valgrind command line (together with --leak-check=full ). Now you will also get backtraces showing where still reachable memory blocks were allocated in your program.
Valgrind Memcheck is a tool that detects memory leaks and memory errors. Some of the most difficult C bugs come from mismanagement of memory: allocating the wrong size, using an uninitialized pointer, accessing memory after it was freed, overrunning a buffer, and so on.
Where are memory leaks found? Explanation: Memory leaks happen when your code needs to consume memory in your application, which should be released after a given task is completed but isn't. Memory leaks occur when we are developing client-side reusable scripting objects.
You allocate the memory, work with it until the program terminates. This is not a memory leak; it doesn't impair the program, and all the memory will be scavenged up automagically when the program terminates. Generally, you should avoid memory leaks.
It is important to have at least one method in place to check for memory leaks. On MacOS, especially if you use XCode, it is quite easy to use Instruments for this. On other platforms, let’s say Linux, Valgrind is one of the best tools. The easiest way is to use Homebrew. If you don’t have it yet, install this first.
On MacOS, especially if you use XCode, it is quite easy to use Instruments for this. On other platforms, let’s say Linux, Valgrind is one of the best tools. The easiest way is to use Homebrew. If you don’t have it yet, install this first. Just paste this into a terminal and you are good to go: Next, install Valgrind: On a Debian based system:
We invoke Valgrind, passing the QEMU command line as the main argument, along with options to specify that the memcheck tool should be used, requesting additional details for all leak types, and directing all output to a log file where it can be analyzed (see the manual for Valgrind options).
A memory leak occurs when an application dynamically allocates memory and neglects to free it when it’s no longer needed. Memory leaks can be difficult to triage, especially when they occur in large applications with complex code paths.
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
84
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
