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.
Related
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 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~~~
So, I've recently noticed that our development server has a steady ~300MB out of 4GB ram left after the finished development of a certain project. Assuming this was due to memory leaks during the development phase, will that memory eventually free itself up or will it require a server restart. Are there any tools that can be used to prevent this in the future (aside from the obvious, 'don't write code that produces memory leaks')? Sometimes they go unseen for a little while and over time I guess they add up as you continue testing your app.
What operating system are you running? Most operating systems these days will clean up leaked memory for a process when the process exits. It is possible that the memory you are seeing in use is actually being used for the filesystem cache. This is nothing to worry about -- the OS will reclaim this memory if necessary.
From: http://learnlinux.tsf.org.za/courses/build/internals/ch05.html
The amount of free memory indicated by
the free command includes the current
size of the buffer cache in its
calculation. This is misleading, as
the amount of free memory indicated
will often be very low, as the buffer
cache soon fills most of user memory.
Don't' panic. Applications are
probably not crowding your RAM; it is
merely the buffer cache that is taking
up all available space. The buffer
cache counts as memory space available
for application use (remembering that
it will be shrunk as required), so
subtract the size of the buffer cache
to see the real amount of free memory
available for application use
It's best to fight them during development, because then it's easier to identify the revision that introduces the leak. As you probably see now, doing it after the fact is very, very hard. Expect a lot of reports when running the tools I recommend below:
http://valgrind.org/
http://www.ibm.com/software/awdtools/purify/
http://directory.fsf.org/project/ElectricFence/
I'd suggest you to run this tools, suppress most warnings about leaks, and then fix them one by one, removing the suppresions.
And then, make sure you regularly run these tools and quickly fix any regressions!
Of course the obvious answer is "Don't write code that produces memory leaks" and it's a valid one, because they can be extremely hard to fix if you have reference counting issues, or complex code in which it's hard to track the lifetime of memory.
To address your current situation you might consider using a tool such as DevPartner for Windows, or Valgrind for Linux/Unix, both of which I've found to be very effective for tracking down memory leaks (as well as other issues such as performance bottlenecks).
Another thing you may wish to consider is to look at your use of pointers and slowly replace them with smart pointers if you can, which should help manage your pointer lifetimes.
And no, I doubt that memory is going to be recovered without restarting the process in which your code is running.
Run the program using the exceptional valgrind on Linux x86 boxes.
A commerical equivilant, Purify, is available on Windows.
These runtime analysis of your program will report memory leaks and other errors such as buffer overflows and unitialised variables.
Static code analysis - Lint and Coverity for example - can also uncover memory leaks and more serious errors.
Lets be specific about what memory leaks cause and how they harm your program:
If you 'leak' memory during operation of your program there is a risk that your application will eventually exhaust RAM and swap, or the address space of available to your program (which can be less than physical RAM) and cause the next allocation to fail. The vast majority of programs will fail to catch this error, as error checking is harder than it seems. The majority of programs will either fail by dereferencing a null pointer or will exit.
If this is on Linux, check the output of 'free' and specifically check the amount of 'cached' ram. If your development work includes a lot of disk I/O, it'll use it for caching files, and you'll see very little 'available' but it's still there if it's needed. For all practical purposes, consider free+cached as available.
The 'free' output is distilled from /proc/meminfo, and you can get more detailed information on the running process in /proc/$pid/{maps,smaps}
In theory when your process exits, any memory it had is released. Is your process exiting?
Don't assume anything, run a memory profiler over it and see what it's doing.
When I was at college we used the Borland C++ Builder 6 IDE
It included CodeGuard, which checks for memory leaks and other memory related issues.
I am not sure if this option is still available on newer versions, but it would be weird for a new version to have less features.
On linux, as mentioned before, valgrind is a good memory leak debugger.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I was looking into Valgrind to help improve my C coding/debugging when I discovered it is only for Linux - I have no other need or interest in moving my OS to Linux so I was wondering if there is a equally good program for Windows.
As jakobengblom2 pointed out, valgrind has a suit of tools. Depending which one you are talking about there are different windows counter parts. I will only mention OSS or free tools here.
1. MemCheck:
Dr. Memory. It is a relatively new tool, works very well on Windows 7. My favorite feature is that it groups the same leaks' allocation stacks in the report.
http://code.google.com/p/drmemory/
I have also used UMDH( http://support.microsoft.com/kb/268343 ) and found it quiet useful and easy to setup. It works from Win2000 to Win7.
AppVerifier is a must have swissknife for windows native code developers, its "memory" checker does similar job
http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx
2. Callgrind:
My favorite is verysleepy ( http://www.codersnotes.com/sleepy ) It is tiny but very useful and easy to use.
If you need more features, AMD CodeAnalyst™ Performance Analyzer is free:
http://developer.amd.com/documentation/videos/pages/introductiontoamdcodeanalystperformanceanalyzer.aspx
Windows Performance Analysis tools is free from Microsoft, not very easy to use but can get the job done if you are willing to spend the time. http://blogs.microsoft.co.il/blogs/sasha/archive/2008/03/15/xperf-windows-performance-toolkit.aspx
Download:
http://msdn.microsoft.com/en-us/performance/cc752957
3. Massif:
Similar(not quite exact match) free tools on windows are:
VMMap from sysinternals : http://technet.microsoft.com/en-us/sysinternals/dd535533
!heap command in windbg : http://hacksoflife.blogspot.com/2009/06/heap-debugging-memoryresource-leak-with.html
4. Cachegrind:
Above mentioned Windows Performance Tools has certain level of L2 cache miss profiling capability but not quite as good and easy to use as Cachegrind.
5. DRD:
Haven't found anything free and as powerful on Windows yet, the only free tool for windows I can find that is slightly close is the "lock" checker in
AppVerifier:
http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx
Why not use Valgrind + Wine to debug your Windows app? See
http://wiki.winehq.org/Wine_and_Valgrind
(Chromium uses this to check the Windows version for memory errors; see
build.chromium.org
and look at the experimental or memory waterfalls, and search for wine.)
There's also Dr. Memory, see
dynamorio.org/drmemory.html
Some more good commercial tools:
Purify
Insure++
For Visual C++, try Visual Leak Detector. When I used it, it detected a memory leak from a new call and returned the actual line in source code of the leak. The latest release can be found at http://vld.codeplex.com/.
Development environment for Windows you are using may contain its own tools. Visual Studio, for example, lets you detect and isolate memory leaks in your programs
i would like to list some tool , hope will be useful
read this article for more detail
Purify
Bounds Checker
Coverity (basically its a code analyzer but, it will catch memory leak in static )
Glow Code
dmalloc
ccmalloc
NJAMD
YAMD
Valgrind
mpatrol
Insure++
Try DUMA
There is Pageheap.exe part of the debugging tools for Windows. It's free and is basically a custom memory allocator/deallocator.
See http://support.microsoft.com/kb/286470
In combination with Visual Studio I generally use Visual Leak Detector or simply _CrtDumpMemoryLeaks() which is a win32 api call. Both are nothing fancy but they get the job done.
I had the chance to use Compuware DevPartner Studio in the past and that was really good, but it's quite expensive.
A cheaper solution could be GlowCode, i just worked with a 5.x version and, despite some problems in attaching to a process i needed to debug, it worked quite well.
I've been loving Memory Validator, from a company called Software Verification.
Viusual Studio can help detecting memory leaks itself. See Microsoft Visual C++ Tips and Tricks -> "Memory Leaks" section.
See also this post in SO
Although real tracing is only possible with the Team Edtion of Visual Studio.
See the "Source Test Tools" link on the Software QA Testing and Test Tool Resources page for a list of similar tools.
I've used BoundsChecker,DevPartner Studio and Intel V-Tune in the past for profiling. I liked V-Tune the best; you could emulate various Intel chipsets and it would give you hints on how to optimize for that platform.
Does Jochen Kalmbach's Memory Leak Detector qualify?
PS: The URL to the latest version is buried somewhere in the article's comment thread.
LeakDiag, UMDH, App Verifier, DebugDiag, are all useful tools to improve robustness of code and find memory leaks.
The Boost Test library can detect memory leaks.
How about the Purify?
Try Intel's Inspector XE product which can help you detect both memory and threading issues: http://software.intel.com/en-us/articles/intel-inspector-xe/
Perhaps CodeSnitch would be something you're after? http://www.entrek.com/codesnitch.html
If you are developing with Borland/CodeGear/Embarcadero C++ Builder, you could use CodeGuard.
More or less all Profilers include checking for memory leaks and show you the stack when the memory was allocated.
I can recommend Intels Parallel Inspector. Simple to use and no recompilation needed. The trial version runs for 30 days.
GlowCode and AtromatedQA also include such capabilites. They all offer free trials.
Compuware DevPartner (aka BoundsChecker) in Contrast needs a slowed down "instrumentation" recompile and the application also runs slower when checking for errors. And BoundsChecker can not work with 64 Bit evsrions at all. We gave up on that tool.
The best tool I ever used is DevPartner BoundsChecker - it's not free but it has an evaluation period.
Another memory tool for your list: Memory Validator.
Not free, but nowhere near as expensive as Purify or Boundschecker.
If you're not afraid of mingw, here are some links (some might work with MSVC)...
http://betterlogic.com/roger/?p=1140
We are just completing a Memory Safety checking tool for Windows, that handles GCC and Micrsoft Visual C (not C++ yet), and are looking for Beta testers.
EDIT June 12, 2011: Not Beta anymore, now production for GCC and Microsoft Visual Studio C.
I found this SF project today:
http://sourceforge.net/p/valgrind4win/wiki/Home/
They are porting valgrind to Windows. Probably in several years we will have a reliable valgrind on windows.
Check out this question: Is there a good Valgrind substitute for Windows? . Though general substitute for valgrind is asked, it mainly discusses memory leak detectors and not race conditions detections.
I used Insure++ which does excellent job in finding c++ memory leaks/corruptions and many other bugs like uninitialized variables, pointer errors, strings etc., It also does visual "Code coverage" and run time memory usage etc.. which give more confident on your code.. You can try it for trail version..
You might want to read what Mozilla is doing regarding memory leaks. One tool in their toolbox is the Hans Boehm garbage collector used as memory leak detector.
You can give a try to RuntimeChecker trial ot to IBM Purify trial..
A free solution would be to use the following code in Visual Studio:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Just write this in the top of all your cpp files.
This will detect memory leaks of your application whenc stopping debug run and list them in the output window. Double clicking on a memory leaks line will higlight you the line where memory is allocated and never released. This may help you : http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
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.