I am using Xcode for debugging of my C program, and I want to make sure that all memory allocations has been freed when the program is finished. However, I am not sure how can I see if there is any alloc that is left not freed.
I know that it is possible to do using Valgrind on machines running on Linux. Would appreciate if someone suggests alternative for Mac OS X Yosemite 10.10.1 and it would be even better if there is a way of doing it on Xcode.
When I am looking at memory accumulation (not being released) I use the Xcode profiler and Heap Shot, see For HowTo use Heap Shot (now named Mark Generation) to find memory creap: bbum blog.
Also see the memory diagnostics under "Edit Scheme""Diagnostics": Enable Scribble, Enable Guard Edges, Enable Guard Malloc and Malloc Stack.
valgrind is available on MacOS.
See valgrind web site:
"X86/Darwin and AMD64/Darwin (Mac OS X 10.9, with limited support for 10.8)."
So, that looks a good alternative to valgrind on linux, if you
want to use MacOS.
Is there any alternative available for checking memory leaks on Cygwin as it does not support Valgrind?
I don't know much about Windows, but you can try this tool, it seems that it has porting the soft on Windows platform:
http://code.google.com/p/drmemory/
Some documentation is available here:
http://www.burningcutlery.com/derek/docs/drmem-CGO11.pdf
Hope this help.
Regards.
Check for DUMA project http://duma.sourceforge.net/. It is a little different than you need, but hope you can find an answer there.
I have recently used CMemLeak to great success.
It is very easy to use, you just have to include it in every header, and detects memory leaks, invalid writes and non heap frees.
It does not detect invalid reads.
I am trying to complete a college assignment, and the marking criteria specifies 5% for memory management - specifically for having no memory leaks.
As I understand it, memory leaks in simple C programs, are only caused by pointers which have become abandoned by the program - ie, malloc/calloc/etc calls which are never have a corresponding free.
My question is in 3 parts:
Whats the simplest way on Solaris
and OSX to 'prove' that you haven't
leaked any memory?
Does XCode have
any tools to help determine memory
leaks?
Does the operating system
release all previously allocated
memory within a c program once the
process ends?
Valgrind is your friend.
For every malloc(), you need to ensure that you have exactly one free().
I haven't worked with XCode, but this forum entry may help.
Yes. It's still poor form to let your running program 'leak,' however.
In general, it's a good idea to learn how to avoid leaks without using tools like a memory debugger (early on) -- especially for your simple programs. It's painful, however: when it comes to building anything non-trivial you'll want to start learning how to use the more advanced debugging tools (like Valgrind, as Alex Reynolds suggested in another answer.)
Answer for Mac OS and an example to be avoided (saved you half an hour).
Mac OS doesn't come with Valgrind or dmalloc. Moreover, Valgrind has some compatibility issues when trying to get it installed in Sierra.
There is utility called "leaks", which I get it running by this:
leaks -atExit --/Contents/Developer/usr/lib/libLeaksAtExit.dylib ./a.out
Unfortunately, this doesn't report obvious memory leaks... Maybe I am using it wrong, but I was just searching for an easy way to check that my C program free'd its memory as it should.
If you have time, then maybe read and use Using OSX Leaks for C Programs on the Command Line?
Resources:
Finding Memory Leaks
Using the "leaks" command on a C/C++ executable
PS: Maybe if used with "iprofiler", then it might be useful, but I didn't had it installed.
there's dmalloc too
I have written a C application that is destined to be on a Solaris SPARC system. However the majority of my development has been on my Mint Linux 64 bit machine.
I have seen I have a small memory leak and have been using Valgrind on Linux to check it out.
My question is: If I run Valgrind on Linux and make all the memory leak stuff 100% (or at least close to that), if I can compile the application on Solaris does it mean that it should also behave the same (meaning I do not have to use Solaris specific memory leak detection tools?)
Reason I ask is I doesn't really have the time to learn all these profiling tools for each platform.....I am hoping that if Valgrind tells me to fix something that the fix will also work on Solaris?
I know the memory management between Linux and Solaris would be quite different, but surely on memory leak detection they would be kind of the same?
Any advice / help would be greatly appreciated ;-)
Lynton
Generally speaking, if the code execution path is the same on both systems and you clean up the memory leaks on one then yes, it will clean them up on the other system too.
It's not quite so straight forward when things differ between the machines though. EG, it tries to do one thing on the linux system and another thing on the solaris system.
Valgrind is a great tool and the best thing to do is try it on linux and see if it cleans up the leaks on solaris too (check with ps or another tool that lists the memory size under solaris and make sure it doesn't increase there).
What memory leak detectors have people had a good experience with?
Here is a summary of the answers so far:
Valgrind - Instrumentation framework for building dynamic analysis tools.
Electric Fence - A tool that works with GDB
Splint - Annotation-Assisted Lightweight Static Checking
Glow Code - This is a complete real-time performance and memory profiler for Windows and .NET programmers who develop applications with C++, C#, or any .NET Framework
Also see this stackoverflow post.
second the valgrind... and I'll add electric fence.
Valgrind under linux is fairly good; I have no experience under Windows with this.
If you have the money: IBM Rational Purify is an extremely powerful industry-strength memory leak and memory corruption detector for C/C++. Exists for Windows, Solaris and Linux. If you're linux-only and want a cheap solution, go for Valgrind.
Mudflap for gcc! It actually compiles the checks into the executable. Just add
-fmudflap -lmudflap
to your gcc flags.
I had quite some hits with cppcheck, which does static analysis only. It is open source and has a command line interface (I did not use it in any other way).
lint (very similar open-source tool called splint)
Also worth using if you're on Linux using glibc is the built-in debug heap code. To use it, link with -lmcheck or define (and export) the MALLOC_CHECK_ environment variable with the value 1, 2, or 3. The glibc manual provides more information.
This mode is most useful for detecting double-frees, and it often finds writes outside the allocated memory area when doing a free. I don't think it reports leaked memory.
Painful but if you had to use one..
I'd recommend the DevPartner BoundsChecker suite.. that's what people at my workplace use for this purpose. Paid n proprietary.. not freeware.
I've had minimal love for any memory leak detectors. Typically there are far too many false positives for them to be of any use. I would recommend these two as beiong the least intrusive:
GlowCode
Debug heap
For Win32 debugging of memory leaks I have had very good experiences with the plain old CRT Debug Heap, that comes as a lib with Visual C.
In a Debug build malloc (et al) get redefined as _malloc_dbg (et al) and there are other calls to retrieve results, which are all undefined if _DEBUG is not set. It sets up all sorts of boundary guards on the heap, and allows you to diplay the results at any time.
I had a few false positives when I was witting some time routines that messed with the library run time allocations until I discovered _CRT_BLOCK.
I had to produce first DOS, then Win32 console and services that would run for ever. As far as I know there are no memory leaks, and in at least one place the code run for two years unattended before the monitor on the PC failed (though the PC was fine!).
On Windows, I have used Visual Leak Detector. Integrates with VC++, easy to use (just include a header and set LIB to find the lib), open source, free to use FTW.
At university when I was doing most things under Unix Solaris I used gdb.
However I would go with valgrind under Linux.
The granddaddy of these tools is the commercial, closed-source Purify tool, which was sold to IBM and then to UNICOM
Parasoft's Insure++ (source code instrumentation) and valgrind (open source) are the two other real competitors.
Trivia: the original author of Purify, Reed Hastings, went on to found NetFlix.
No one mentioned clang's MSan, which is quite powerful. It is officially supported on Linux only, though.
This question maybe old, but I'll answer it anyway - maybe my answer will help someone to find their memory leaks.
This is my own project - I've put it as open source code:
https://sourceforge.net/projects/diagnostic/
Windows 32 & 64-bit platforms are supported, native and mixed mode callstacks are supported.
.NET garbage collection is not supported. (C++ cli's gcnew or C#'s new)
It high performance tool, and does not require any integration (unless you really want to integrate it).
Complete manual can be found here:
http://diagnostic.sourceforge.net/index.html
Don't be afraid of how much it actually detects leaks it your process. It catches memory leaks from whole process. Analyze only biggest leaks, not all.
I'll second the valgrind as an external tool for memory leaks.
But, for most of the problems I've had to solve I've always used internally built tools. Sometimes the external tools have too much overhead or are too complicated to set up.
Why use already written code when you can write your own :)
I joke, but sometimes you need something simple and it's faster to write it yourself.
Usually I just replace calls to malloc() and free() with functions that keep better
track of who allocates what. Most of my problems seem to be someone forgot to free and this helps to solve that problem.
It really depends on where the leak is, and if you knew that, then you would not need any tools. But if you have some insight into where you think it's leaking, then put in your own instrumentation and see if it helps you.
Our CheckPointer tool can do this for GNU C 3/4 and, MS dialects of C, and GreenHills C. It can find memory management problems that Valgrind cannot.
If your code simply leaks, on exit CheckPointer will tell you where all the unfreed memory was allocated.