I need to get the following to analyze a memory leak issue. How to do that?
Orphan Block Addresses Orphan Call
Stack
Are there any good resources/tools to know about/fix memory leaks.
Thanks
If you're on linux, use valgrind. It's your new best friend. I'm not sure what tools are available for Windows.
valgrind --leak-check=full
The Microsoft Application Verifier performs memory analysis similar to valgrind if you are on a Windows platform.
In Windows, you can use the MiniDumpWriteDump function in dbghelp.dll.
How to create minidump for my process when it crashes?
This can be very helpful in tracking down errors in deployed applications because you can use your debug symbols to inspect a minidump made in the field with no debug info. It's not very useful for tracking memory leaks, however.
For memory leaks under Windows (aside from commercial tools like Purify, BoundsChecker and GlowCode, of course) you can use WinDbg from the free Debugging Tools for Windows package, along with Win32 heap tags to track down the source of memory leaks.
http://www.codeproject.com/KB/cpp/MemoryLeak.aspx
http://blogs.msdn.com/alikl/archive/2009/02/15/identifying-memory-leak-with-process-explorer-and-windbg.aspx
Yes, as J. Paulett commented, at least on the Linux platform Valgrind is an excellent starting point.
On Windows I was able to get the necessary details using UIforETW, which is handling the necessary command line arguments for xperf.
This blog post explains everything in great detail: https://randomascii.wordpress.com/2015/04/27/etw-heap-tracingevery-allocation-recorded/
Recording
Step 1: A TracingFlags registry entry is created and set to ‘1’ in the Image File Execution Options for each process name that will be trace to tell the Windows heap to configure itself for tracing when a process with that name is launched. As is always the case with Image File Execution Options the options don’t affect already running processes – only processes launched when the registry key is set are affected.
Step 2: An extra ETW session is created using the “-heap -Pids 0” incantation. This session will record information from processes that had a TracingFlags registry entry of ‘1’ when they started.
The details are a bit messy but now that UIforETW is written I don’t have to bother explaining the details, and you don’t have to pretend to listen. If you want to record a heap trace use UIforETW, and if you want to know how it works then look at the code, or click the Show commands button to see most of the dirty laundry.
Analysis
The recording can be inspected with WPA (Windows Performance Analyzer) which can be conveniently launched from UIforETW.
The recommended columns are: Process, Handle, Type, Stack.
The allocation types are:
AIFO – Allocated Inside Freed Outside (hint, hint)
AOFI – Allocated Outside Freed Inside
AOFO – Allocated Outside Freed Outside
AIFI – Allocated Inside Freed Inside
Related
I research an embedded device that use GLIBC 2.25.
When I look at /proc/PID/maps I see under the heap section some anonymous sections ,I understand that sections create when the process use new
I dump those sections with dd and there is there interesting value that I want to understand is that buffer allocated or free, and what is the size of this buffer.
How can I do that please?
You can use the gdb (GNU Debugger) tool to inspect the memory of a running process. You can attach to the process using its PID and use the x command to examine memory at a specific address. You can also use the info proc mapping command to view the memory maps of the process, including the size of the heap. Additionally, you can use the heap command to list heap blocks and the malloc_info command to show detailed information about heap blocks.
You can also use the malloc_stats function to display information about the heap usage such as the number of bytes allocated, the number of bytes free and the number of bytes in use.
You can also use the pmap command to display the memory map of a process, including the heap size. This command is available on some systems and may not be present on others.
It's also worth noting that the /proc/PID/maps file can also give you an idea about the heap section of a process.
Please keep in mind that you need to have the right permission to access the process you want to inspect.
Instead of analyzing the memory from proc, you may want to try following options, limited to your env.
use tools like valgrind if you suspect any kind of leaks or invalid read/writes.
rather than looking at output of dd, attach to running process and inspect memory within process, gives you context to make sense of memory usage.
use logging to dump addresses of allocation/free/read/write. This allows you to build better understanding of memory usage.
You may have to use all of the above options depending upon the complexity of your task.
What tools exist to help finding memory leaks for handles?
I have a file.exe and an inproc-server dll, which is using file.exe. I have about 10 memory leaks of handles evertyime it completes its operation.
Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653) is one of the SysInternals tools that you can use to show the handles that a program has allocated. You have to configure the lower pane view to show handles in order to see them. It tells you the type of handle, which may help in finding the source of the leak. It won't tell you an allocation path, but it is still useful when other tools also can't detect the leaks.
I've also used DevPartnerStudio successfully to find a lot of leaks. (http://www.microfocus.com/products/micro-focus-developer/devpartner/index.aspx). It does have a tendency to report false leaks, so you have to play with the settings to make sure you're getting accurate results. It is a very good product and I always suggest buying it when doing C++ development on Windows.
I am currently looking into an issue where an application is using alot of private memory for a C++ app. It looks like alot is in commited and reserve memory based on the dump analysis.
I use Windbg. Is there any way I can see what excactly is in commited and reserve memory? I have narrowed it down to one specific heap.
My theory is that it's not being released. I cannot live debug, I only have dumps to go on.
I have already used the command !address -filter and get a pretty little out put, but how do i move forward?
Any suggestions would help.
You can use the !heap -s command to get memory usage info in WinDbg. There is a tutorial on Leak Detection with windbg here.
There are few ways how you can diagnoze memory leaks:
Using heap stack trace, and then examining process dump in WinDbg
Taking snapshots of process memory state using UMDH tool.
The later option (UMDH tool) is part of WinDbg package and is usually the easiest option to investigate memory leaks. Both options are actually based on the same feature, which is an ability of NT heap to keep call stacks at the allocation along with the allocated entry.
Note that besides leaking memory in heaps, you might have other types of leaks that would result in increase of commited memory space. For example you might have called VirtualAlloc directly and forgot to VirtualFree it.
I have a C++ Application, when I observe Task Manager, it shows that applicaiton's memory usage increases gradually.
I manually check my source code, and I used Visual Leak Detector for Visual C++ to find memory leak, but I couldn't find any.
Is it 100% that there is a memory leak, and I couldn't find it or is there any possibility that Task Manager misguide me?
It isn't. It has several options for memory statistics (use View + Columns) and the version matters but the default view shows the working set. How much of the virtual memory your program uses is actually in RAM. That's a statistical number that can change very quickly. Just minimize the main window of your app for example.
The VM size it can show isn't great either. That number includes free heap blocks. Getting actual memory in use is very tricky, read the small print in the SDK article for HeapWalk.
It is useless for leak detection, unless you leak gobs of it.
I use Process Explorer as replacement for Task Manager. It shows history graphs for CPU/mem usage
I use Extended Task manager
http://www.warecase.com/products.asp
This is useful for debugging purpose especially to check if a thread exists or not and other such cases. It can provide lots of information if you have pdb for your process or application.
Probably you can use DevPartner for identifying memory leaks. It is very useful.
An application I am working with is exhibiting the following behaviour:
During a particular high-memory operation, the memory usage of the process under Task Manager (Mem Usage stat) reaches a peak of approximately 2.5GB (Note: A registry key has been set to allow this, as usually there is a maximum of 2GB for a process under 32-bit Windows)
After the operation is complete, the process size slowly starts decreasing at a rate of 1MB per second.
I am trying to figure out the easiest way to quickly determine who is freeing this memory, and where it is being free'd.
I am having trouble attaching a memory profiler to my code, and I don't particularly want to override the new/delete operators to track the allocations/deallocations (IOW, I want to do this without re-compiling my code).
Can anyone offer any useful suggestions of how I could do this via the Visual Studio debugger?
Update
I should also mention that it's a multi-threaded application, so pausing the application and analysing the call stack through the debugger is not the most desirable option. I considered freezing different threads one at a time to see if the memory stops reducing, but I'm fairly certain this will cause the application to crash.
Ahh! You're looking at the wrong counter!
Mem Usage doesn't tell you that memory is being freed. Only that the working set is being purged! This could mean some other application needs memory, or the VMM decided to mark some of your process's pages as Stand By for some other process to quickly use. It does not mean that VirtualFree, HeapFree or any other free function is being called.
Look at the commit size (VM Size, Private Bytes, etc).
But if you still want to know when memory is being decommitted or freed or what-have-you, then break on some free calls. E.g. (for Visual C++)
{,,kernel32.dll}HeapFree
or
{,,msvcr80.dll}free
etc.
Or just a regular function breakpoint on the above. Just make sure it resolves the address.
cdb/WinDbg let you do it via
bp kernel32!HeapFree
bp msvcrt!free
etc.
Names may vary depending on which CRT version you use and how you link against it (via /MT or /MD and its variants)
You might find this article useful:
http://www.gamasutra.com/view/feature/1430/monitoring_your_pcs_memory_usage_.php?print=1
basically what I had in mind was hooking the low level allocation functions.
A couple different ideas:
The C runtime has a set of memory debugging functions; you'd need to recompile though. You could get a snapshot at computation completion and later, and use _CrtMemDifference to see what changed.
Or, you can attach to the process in your debugger, and cause it to dump a core before and after the memory freeing. Using NTSD, you can see what heaps are around, and the sizes of things. (You'll need a lot of disk space, and a fair amount of patience.) There's a setting (I think you get it through gflags, but I don't remember) that causes it to save a piece of the call stack as part of the dump; using that you can figure out what kind of object is being deallocated. Unfortunately, it only stores 4 or 5 stack frames, so you'll likely have to do something more clever as the next step to figure out where it's being freed. Either look at the code ("oh yeah, there's only one place where that can happen") or put in breakpoints on those destructors, or add tracing to the allocations and deallocations.
If your memory manager wipes free'd data to a known value (usually something like 0xfeeefeee), you can set a data breakpoint on a particular instance of something you're interested in. When it gets free'd, the breakpoint will trigger when the memory gets wiped.
I recommend you to check UMDH tool that comes with Debugging Tools For Windows (You can find usage and samples in the debugging tools help). You can snap shot running process's heap allocations with stack trace and compare them.
You could try Memory Validator to monitor the allocations and deallocations. Memory Validator has a couple of features that will help you identify where data is being deallocated:
Hotspots view. This can show you a tree of all allocations and deallocations or just all allocations or just all deallocations. It presents the data as a percentage of memory activity (based on amount of memory (de)allocated at a given location).
Analysis view. You can perform queries asking for data in a given address range. You can restrict these queries to any of alloc, realloc, dealloc behaviours.
Objects view. You can view allocations by type and see the maximum number of objects of each type (plus lots of other stats). Right click on a type to get a context menu, choose show all deallocations - will show deallocation locations for that type on Analysis tab.
I think the Hotspots view may give you the insight you need.