In a huge C++ builder 2010 application with several DLL's being built and linked etc. What would be the best way to trace down memory leaks that accumulate over a long period of time? Say that the application has to be running for a week or something on the target machine before it becomes an issue. Let's assume that there is no profiling application available like AQ Time or something similar. Just using the standard IDE and perhaps some code.
My initial idea was to write a macro to use in all classes that keeps track of the number of instances and space used of each class type to start with.
The RTL uses FastMM as its memory manager. FastMM supports memory leak reporting and tracing. The native version of FastMM that is included in the RTL is a stripped down version, but it does support minimal leak reporting. You can set the RTL's global ReportMemoryLeaksOnShutdown variable to true at run-time and FastMM will generate a basic leak report when the app is closed. For more advanced usage, you can download the full version of FastMM and add it to your app, which will replace the RTL's native version. You can then configure FastMM as desired.
Related
I have noticed that Valgrind is not detecting resources created with the C API of HDF5 and that are not closed before the end of the program, though I launched it with the option --leak-check=full. Is that normal ?
I often rely on Valgrind before shipping the code, but today I was surprised and frustrated when reviewing the code that it was not detected by it.
valgrind memcheck tool detects memory allocated/released by the 'standard' allocators, such as malloc/free/new/delete/...
If the C API of HDF5 is not using (internally) the above standard allocators,
then there is no way that valgrind could guess by itself what to monitor.
If HDF5 is implementing its own heap management (e.g.based on mmap, and cutting
these blocks in smaller allocated blocks),
then valgrind provides 'client requests' allowing to have some valgrind support
for such non standard allocators. But that all implies some work in the HDF5
sources.
See e.g. http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools
for more information about how to describe such non standard allocators.
Some libraries/tools that are implementing their own non standard allocators
have sometime a way (e.g. an environment variable) to indicate to bypass
these non standard allocators, and still use malloc/free/...
Again, up to HDF5 to provide this.
If now HDF5 really uses the standard allocators and valgrind cannot track
what it does, then file a bug on valgrind bugzilla.
We are using Nashorn to use javascript from java (JDK 1.8 U66),after some profiling we are seeing a larger data is getting occupied by jdk.nashorn.internal.scripts.JO4P0
Object. Would like to know if any one have any idea?
jdk.nashorn.internal.scripts.JO4PO and other similar instances are used to represent scripts objects from your scripts. But, you need to provide more info for further investigation. I suggest you please write to nashorn-dev openjdk alias with profiler output + more info. about your application (like to project, if open source, would be useful
Created application is working toooo slow, looks like there are a lot of memory leaks, there are a lot of pointers. So, please, can you advice some effective tool for run-time errors and memory leaks detection in Visual Studio C++?
You can use deleaker. It must help you.
I know 2 good tools for windows: Purify and Insure++.
For linux: Valgrind.
If you use the debug version of the CRT library , you can use find all memory leaks very easily.
Basically after including appropriate headers you call
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
somewhere in the beginning of you program.
Before the program exits you should call
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );
Which dumps all the memory leaks to Debug Output Window.
But the application being slow might be unrelated to memory leaks, For performance profiling you can follow directions as per Find Application Bottlenecks with Visual Studio Profiler
For catching bad C++ constructs at compile time, you can use the static code analysis feature of Visual Studio 2010 or later.
Greetings all,
I'm the developer of a rather large C# Windows Explorer extension. As you can imagine, there is a lot of P/Invoke involved, and unfortunately, I've confirmed that it's leaking unmanaged memory somewhere. However, I'm coming up empty as to how to find the leak. I tried following this helpful guide, which says to use WinDBG. But, when I try to use !heap, it won't let me because I don't have the .PDB files for explorer.exe (and the public symbol files aren't sufficient, apparently).
Help?
I've used many time UMDH with very good results. The guide you mentioned describing WinDbg uses the same method as UMDH, based on ability of debug heap to record stack traces for all allocations. The only difference is that UMDH does it automated -- you simply run umdh from command line and it creates snapshot of all current allocations. Normally you to repeate the snapshots two or more times, then you calculate 'delta' between two snapshots (also using umdh.exe). The information on the 'delta' file gives you all new allocations that happen between your snapshots, sorted by the allocation size.
UMDH also needs symbols. You will need at least symbols for ntdll.dll (heap implementation lives there). Public symbols available on public symbols from http://msdl.microsoft.com/download/symbols will work fine.
Make sure you are using correct bitness of the umdh.exe. Explorer.exe is 64 bit on 64 bit OS, so if your OS is 64 bit you need to use 64 bit umdh.exe -- i.e. download appropriate bitness of Windows debugging tools.
We have .NET application (actually an IronPython app). We noticed that overtime the app becomes bigger in memory and sluggish.
Using WINDBG (!eeheap -loader), we noticed the that the LoaderHeap is getting bigger (150MB increase per day). From the !eeheap output it seems that the increase is due to HostCodeHeap (objects?).
I'd like to know what are these objects and why how can I prevent them from growing to infinity.
Thanks!
They are likely objects created for dynamically emitted code. Several components in the framework do this, and it may well be that IronPython uses some on its own.
I'd heard of similar issues while using Linq-TO-SQL, XML serialization, compiled XSLT transforms and other dynamically generated code.
See also "Leaking Unmanaged Heap Memory" near figure 2 in this MSDN magazine article.