Question or issue on macOS:
Today I synced with original valgrind repo with patch and tested with Mojave 10.14.6 the thing is that it works still for simple projects but not for a complex one I have maybe someone join as a contributor to help?
I tried to install Valgrind with brew install Valgrind and got :
在 configure 文件中，valgrind的注释提到在MacOS下会同时编译i386和x8664，这是问题的根本原因，或者说valgrind在Mojave下编译的坑。幸好 configure 提供了只编译64位的选项，不需要修改 configure 文件。 总结一下，你要做的是. Valgrind on Mojave using Docker 2019-11-29 Valgrind is a very useful tool that allows you to spot memory leaks, memory corruptions and other bugs in your program which would have otherwise been difficult to find and track down.
I tried brew install –HEAD Valgrind.
Instead, after successfully installing the dependencies autoconf, automake and libtool, when it tries to install valgrind, I get a configure error:
My OS is macOS Mojave(10.14), so does it mean that I can’t install a functioning Valgrind with Homebrew presently?
How to solve this problem?
Solution no. 1:
A (rather painful) install from source workaround based on this patch, this post and this answer.
If you get the following error: No rule to make target '/usr/include/mach/mach_vm.defs’, you will need to run xcode-select --install. You might need to install Xcode from the app store if you don’t already have it. Once that’s done, you will need to edit the coregrind/Makefile:
Search for:
After double checking the below folder exists, prefix every line with:
End result should be:
Now run make again and the includes should be found. But that doesn’t necessarily mean it will compile. I got the following error:
A fix for this is to add the following line:
to the following files:
coregrind/m_syscall.ccoregrind/m_syswrap/syswrap-darwin.ccoregrind/vg_preloaded.c
Finally, you need to cross your fingers hoping no other errors show up:
Solution no. 2:
You may use Experimental Version of Valgrind for macOS 10.14.5 Mojave at:
The command to use it is:
It is still experimental and needs some work but for simple projects works already… Enjoy!
Solution no. 3:
addition: I found this one worked for me on my OSX 10.14
A branch that is working to get OSX correct. something to tide us over until we get a real valgrind version fixed.
Solution no. 4:
I am having the same issue. It seems like valgrind is not compatible with the newest macOS(10.14 Mojave). Tried installing it the High Sierra way (https://www.gungorbudak.com/blog/2018/04/28/how-to-install-valgrind-on-macos-high-sierra/) and got the same output you described. The only solution I can offer you right now is either working on virtual machine (https://www.virtualbox.org/) or using Docker (https://www.gungorbudak.com/blog/2018/06/13/memory-leak-testing-with-valgrind-on-macos-using-docker-containers/).
See Full List On Github.com
Solution no. 5:
I have just found a working solution to use VALGRIND on my Mac (Mojave 10.14.6). Just run this command :
(From https://github.com/LouisBrunner/valgrind-macos)
Hope it will work for you.
Solution no. 6:
Not a proper solution for macOs, but for the time being, I created a docker image. After installing docker for macOS, this is how to start valgrind:
Solution no. 7:
As of 2019-NOV-30, it is possible to build against OS X 10.14.6 via https://github.com/sowson/valgrind and https://github.com/LouisBrunner/valgrind-macos
However, there are many test failures (see the LouisBrunner link), noise during runs, and SEGVs when running against non-trivial programs: installing is, well, installing. YMMV.
Solution no. 8:
You can follow alex.m’s answer to get valgrind, but if you’r using it on a int main() { return 0; } program, you’ll get many weird errors, and non-existing allocs / free.
To ‘hide’ these annoying errors, you can follow theses steps (it’s more a workaround than a real fix) (based on this wiki page and some research in Valgrind’s source code):
- First, create and compile a
int main() { return 0; }program. - Execute the following command (to create file containing error suppression):
valgrind --leak-check=full --show-reachable=yes --error-limit=no --gen-supressions=all --log-file=$YOUR_LOG$ $YOUR_BINARY$
- Using this gawk script, create the
.suppvalgrind file:
cat ./$YOUR_LOG$ | ./$YOUR_SCRIPT_FILE$ > minimal.supp
- Copy and Past
minimal.suppcontent at the end of$YOUR_VALGRIND_INSTALLATION_PATH$/lib/valgrind/default.suppfile
And you are done! Weird and nonexistent errors will be ignored.
If you also want’s to remove the non-existing allocs, frees etc, you can directly edit Valgrind’s source code. Or just use heapusage for leak-tracking
Solution no. 9:
(works on mojave 10.14.6)
Solution no. 10:
As others have mentioned, Louis Brunner maintains a working version at https://github.com/LouisBrunner/valgrind-macos.
This worked for me for MacOS 10.15.7 Catalina.
Hope this helps!
Note: Valgrind is Linux only. If you aren't running Linux, or want a tool designed from the start to make debugging segfaults and memory issues easier, check out Cee Studio, a fully online C and C++ development environment from our sponsor. Cee Studio provides instant and informative feedback on memory issues.Valgrind is a multipurpose code profilingand memory debugging tool for Linux when on the x86 and, as of version 3,AMD64, architectures. Itallows you to run your program in Valgrind's own environment that monitorsmemory usage such as calls to malloc and free (or new and delete in C++). Ifyou use uninitialized memory, write off the end of an array, or forget to freea pointer, Valgrind can detect it. Since these are particularly commonproblems, this tutorial will focus mainly on using Valgrind to find thesetypes of simple memory problems, though Valgrind is a tool that can do a lotmore.
Alternatively, for Windows users who wantto develop Windows-specific software, you might be interested in IBM's Purify, which hasfeatures similar to Valgrind for finding memory leaks and invalid memoryaccesses. A trial download is available.
Getting Valgrind
If you're running Linux and you don't have a copy already, you can getValgrind from the Valgrinddownload page.Installation should be as simple as decompressing and untarring using bzip2(XYZ is the version number in the below examples)which will create a directory called valgrind-XYZ; change into that directoryand runNow that you have Valgrind installed, let's look at how to use it.
Finding Memory Leaks With Valgrind
Memory leaks are among the most difficult bugs to detect because they don'tcause any outward problems until you've run out of memory and your call tomalloc suddenly fails. In fact, when working with a language like C or C++that doesn't have garbage collection, almost half your time might be spenthandling correctly freeing memory. And even one mistake can be costly ifyour program runs for long enough and follows that branch of code.When you run your code, you'll need to specify the tool you want to use;simply running valgrind will give you the current list. We'll focus mainly onthe memcheck tool for this tutorial as running valgrind with the memcheck toolwill allow us to check correct memory usage. With no other arguments, Valgrind presents a summary of calls to free andmalloc: (Note that 18490 is the process id on my system; it will differbetween runs.)If you have a memory leak, then the number of allocs and the number of freeswill differ (you can't use one free to release the memory belonging to morethan one alloc). We'll come back to the error summary later, but for now,notice that some errors might be suppressed -- this is because some errorswill be from standard library routines rather than your own code.
See All Results For This Question
If the number of allocs differs from the number of frees, you'll want to rerunyour program again with the leak-check option. This will show you all of thecalls to malloc/new/etc that don't have a matching free.
For demonstration purposes, I'll use a really simple program that I'll compileto the executable called 'example1'This will result in some information about the program showing up, culminatingin a list of calls to malloc that did not have subsequent calls to free:This doesn't tell us quite as much as we'd like, though -- we know that thememory leak was caused by a call to malloc in main, but we don't have the linenumber. The problem is that we didn't compile using the -g option of gcc,which adds debugging symbols. So if we recompile with debugging symbols, weget the following, more useful, output:Now we know the exact line where the lost memory was allocated. Although it'sstill a question of tracking down exactly when you want to free that memory,at least you know where to start looking. And since for every call to mallocor new, you should have a plan for handling the memory, knowing where thememory is lost will help you figure out where to start looking.
Getting Valgrind
If you're running Linux and you don't have a copy already, you can getValgrind from the Valgrinddownload page.Installation should be as simple as decompressing and untarring using bzip2(XYZ is the version number in the below examples)which will create a directory called valgrind-XYZ; change into that directoryand runNow that you have Valgrind installed, let's look at how to use it.
Finding Memory Leaks With Valgrind
Memory leaks are among the most difficult bugs to detect because they don'tcause any outward problems until you've run out of memory and your call tomalloc suddenly fails. In fact, when working with a language like C or C++that doesn't have garbage collection, almost half your time might be spenthandling correctly freeing memory. And even one mistake can be costly ifyour program runs for long enough and follows that branch of code.When you run your code, you'll need to specify the tool you want to use;simply running valgrind will give you the current list. We'll focus mainly onthe memcheck tool for this tutorial as running valgrind with the memcheck toolwill allow us to check correct memory usage. With no other arguments, Valgrind presents a summary of calls to free andmalloc: (Note that 18490 is the process id on my system; it will differbetween runs.)If you have a memory leak, then the number of allocs and the number of freeswill differ (you can't use one free to release the memory belonging to morethan one alloc). We'll come back to the error summary later, but for now,notice that some errors might be suppressed -- this is because some errorswill be from standard library routines rather than your own code.
See All Results For This Question
If the number of allocs differs from the number of frees, you'll want to rerunyour program again with the leak-check option. This will show you all of thecalls to malloc/new/etc that don't have a matching free.
For demonstration purposes, I'll use a really simple program that I'll compileto the executable called 'example1'This will result in some information about the program showing up, culminatingin a list of calls to malloc that did not have subsequent calls to free:This doesn't tell us quite as much as we'd like, though -- we know that thememory leak was caused by a call to malloc in main, but we don't have the linenumber. The problem is that we didn't compile using the -g option of gcc,which adds debugging symbols. So if we recompile with debugging symbols, weget the following, more useful, output:Now we know the exact line where the lost memory was allocated. Although it'sstill a question of tracking down exactly when you want to free that memory,at least you know where to start looking. And since for every call to mallocor new, you should have a plan for handling the memory, knowing where thememory is lost will help you figure out where to start looking.
There will be times when the --leak-check=yes option will not result inshowing you all memory leaks. To find absolutely every unpaired call to freeor new, you'll need to use the --show-reachable=yes option. Its output isalmost exactly the same, but it will show more unfreed memory.
Finding Invalid Pointer Use With Valgrind
Valgrind can also find the use of invalid heap memory using the memcheck tool.For instance, if you allocate an array with malloc or new and then try toaccess a location past the end of the array:Valgrind will detect it. For instance, running the following program,example2, through Valgrindwithresults in the following warningWhat this tell us is that we're using a pointer allocated room for10 bytes, outside that range -- consequently, we have an 'Invalid write'. Ifwe were to try to read from that memory, we'd be alerted to an 'Invalid readof size X', where X is the amount of memory we try to read. (For a char,it'll be one, and for an int, it would be either 2 or 4, depending on yoursystem.)As usual, Valgrind prints the stack trace of function calls so that we knowexactly where the error occurs.Detecting The Use Of Uninitialized Variables
Another type of operation that Valgrind will detect is the use of anuninitialized value in a conditional statement. Although you should be in thehabit of initializing all variables that you create, Valgrind will help findthose cases where you don't. For instance, running the following code asexample3through Valgrind will result in Valgrind is even smart enough to know that if a variable is assigned the valueof an uninitialized variable, that that variable is still in an'uninitialized' state. For instance, running the following code:in Valgrind as example4 results in the following warning:You might think that the problem was in foo, and that the rest of the callstack probably isn't that important. But since main passes in anuninitialized value to foo (we never assign a value to y), it turns out thatthat's where we have to start looking and trace back the path of variableassignments until we find a variable that wasn't initialized.This will only help you if you actually test that branch of code, and inparticular, that conditional statement. Make sure to cover all executionpaths during testing!
What else will Valgrind Find
Valgrind will detect a few other improper uses of memory: if you call freetwice on the same pointer value, Valgrind will detect this for you; you'll getan error:along with the corresponding stack trace.Valgrind also detects improperly chosen methods of freeing memory. Forinstance, in C++ there are three basic options for freeing dynamic memory:free, delete, and delete[]. The free function should only be matched with acall to malloc rather than a call to, say, delete -- on some systems, you might be able to get away with notdoing this, but it's not very portable. Moreover, the delete keyword should only be paired with the new keyword (for allocation of single objects), and the delete[] keyword should only bepaired with the new[] keyword (for allocation of arrays). (Though some compilers will allow you to get away with using the wrong version of delete,there's no guarantee that all of them will. It's just not part of thestandard.)
If you do trigger one of these problems, you'll get this error: which really should be fixed even if your code happens to be working.
What Won't Valgrind Find?
Valgrind doesn't perform bounds checking on static arrays (allocated on thestack). So if you declare an array inside your function:then Valgrind won't alert you! One possible solution for testing purposes issimply to change your static arrays into dynamically allocated memory takenfrom the heap, where you will get bounds-checking, though this could be a messof unfreed memory.A Few More Caveats
What's the drawback of using Valgrind? It's going to consume more memory --up to twice as much as your program normally does. If you're testing anabsolutely huge memory hog, you might have issues. It's also going to takelonger to run your code when you're using Valgrind to test it. This shouldn'tbe a problem most of the time, and it only affects you during testing. But ifyou're running an already slow program, this might affect you.Finally, Valgrind isn't going to detect every error you have -- if you don'ttest for buffer overflows by using long input strings, Valgrind won't tell youthat your code is capable of writing over memory that it shouldn't betouching. Valgrind, like another other tool, needs to be used intelligentlyas a way of illuminating problems.
Summary
Valgrind is a tool for the x86 and AMD64 architectures and currently runsunder Linux. Valgrind allows the programmer to run the executable inside itsown environment in which it checks for unpaired calls to malloc and other usesofinvalid memory (such as ininitialized memory) or invalid memory operations(such as freeing a block of memory twice or calling the wrong deallocatorfunction). Valgrind does not check use of statically allocated arrays.Related articles
DynamicMemory Allocation, Part 1: Advanced Memory Management
Dynamic Memory Allocation, Part 2: Dynamic Memory Allocation and Virtual Memory
Dynamic Memory Allocation, Part 3: Customized Allocators with Operator New and Operator Delete
Dynamic Memory Allocation, Part 4: Common Memory Management Problems in C++
UnderstandingPointers
Using auto_ptr toavoid memory leaks
