Best way to find memory leaks in a C program - c

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

Related

Hunting for memory leaks on embedded system without valgrind (or using minimal valgrind-like application)

I'm working with embedded linux development, and we're currently having some trouble with some memory page allocation faults, which led me to believe we have a leak somewhere.
Currently, I am trying to cross compile valgrind to use on our system, but I'm losing my faith on this solution because of the sheer amount of memory valgrind will use up (we have serious memory restrictions).
This has made me wonder: is there any way of hunting for a memory leak without valgrind or with a valgrind-like application with minimal memory usage? Creating wrappers for malloc() and free() is out of question.
Also, the test that caused the allocation failures was a simple stress test of copying a file n times and checking its md5sum, in case anyone is curious.
I'm using the Linaro toolchain for cross compiling, glibc 2.15, and the system is set up without a swap partition. The system has around 64MB of RAM, making valgrind, or any other memory intensive application a tad difficult to use.
Regards,
Guilherme

Since you are using glibc, you should have its built-in memory-tracing support available to you. Your program would enable this by calling mtrace(3) at or near startup. mtrace() installs hook functions into the memory allocator to log allocations and deallocations, under runtime control via environment variable MALLOC_TRACE.
You probably also want to be aware of mtrace(1), a Perl script for interpreting log files produced by the mtrace facility.
This facility traces only allocations and deallocations, which is much less than Valgrind does. Nevertheless, those are the main items of interest when you are looking for a memory leak.

Can using Valgrind on Linux also help when the app is compiled on Solaris?

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).

Memory allocation

I am experimenting with the c-language right at the moment, yet i have some trouble with memory allocation. After some time i have to restart my computer because my memory runs full. Is there a way to let the compiler tell me which arrays do not get deallocated after the program has run?
Thx for answers

you can use valgrind to do that.
http://tldp.org/HOWTO/Valgrind-HOWTO/
http://valgrind.org/
use it on your compiled program with --leak-check=yes

You didn't tell us anything about your compiler, OS, platform... so the rest could only be wild guesses.
This sounds much that you have dead processes or something like that that keep eating your memory in the background. On linux you have top (and inside top press M) to inspect the processes running on your system and how much memory, time etc they consume. Do that to see what is happening on your machine and don't reboot it blindly without knowing the reason.
There are equivalent tools on all other operating systems that let you inspect the current state of processes.

You have tools that can tell you about memory leaks. Compilers i am afraid may not be useful for tha tpurpose.
You can also use DevPartner or Valgrind to analyse your memory leaks in case you are suspecting them. But for your system to be restarted because of memory issues how long do you run the application before you perform a restart.
How did you get to know that this is a memory related issue.

You better check your source code first, if you are under Linux, using 'splint' to your source and that will display you a lot, try to fix those warnings or errors, if everything gets done, recompile your source and try 'valgrind' to the exacutable.
You can see the reference of splint through its official website and so as valgrind.
splint: www.splint.org
valgrind: valgrind.org
Good luck~~~

Finding where memory was last freed?

Very general:
Is there an easy way to tell which line of code last freed a block of memory when an access violation occurs?
Less general:
My understanding of profilers is that they override the allocation and deallocation processes. If this is true, might they happen to store the line of code that last freed a section of memory so that when it later crashes because of an access violation, you know what freed it last?
Specifics:
Windows, ANSI C, using Visual Studio

Yes!
Install the Windows Debugging Tools and use Application Verifier.
File -> Add Application, select your .exe
Under Basics, select Memory and Heaps.
Run the debug build of your program under ntsd (ntsd yourprogram.exe).
Reproduce the bug.
Now when you make the crash happen, you will get additional information in the debugger from AppVerifier. Use !avrf (may take a long time to run (minutes)) and it will try to give you as much useful information as possible.
You can all use the dps command on the memory address to get all the stored stack info (allocation, deallocation, etc).
You can also use the !heap command on the memory address:
0:004> !heap -p -a 0x0C46CFE0
Which will dump information as well.
Further Reading:
Advanced Windows Debugging, Hewardt and Pravat
Debugging with PageHeap

Short answer: no.
What you need is a debug malloc. I don't keep up with Windows any longer but there are several about, including this free one.
Update
Looks like Visual Studio C has a built in version. See here
When the application is linked with a
debug version of the C run-time
libraries, malloc resolves to
_malloc_dbg. For more information about how the heap is managed during
the debugging process, see The CRT
Debug Heap.
... and see here for _malloc_dbg.

No, not unless you provide your own allocators (e.g. by overloading new/delete) to store this information.
What profilers do is highly dependent on what they're profiling. I'm not aware of any profiler that tracks what you're looking for.
Perhaps if you provided more details on your situation people could suggest an alternative means of diagnosing the problem you're encountering.

Memory leak detectors for C?

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.

Resources