I fear that some of my code is causing memory leaks, and I'm not sure about how to check it. Is there a tool or something for MacOS X?
Thank you
Yes - there's an application called MallocDebug which is installed as part of the Xcode package.
You can find it in the /Developer/Applications/Performance Tools folder.
Apple has a good description of how to use MallocDebug on OS X on their developer pages.
document on finding leaks in general
enabling debug features of malloc in particular.
Of course UNIX provides a quick and dirty way of detecting memory leaks... top.
Launch your app and watch the system memory allocated to your process over time. If it continually grows when it shouldn't then there is likely a memory leak. At which point you break out Valgrind or use MallocDebug, etc.
Of course if you use smart pointers and/or RAII, then you shouldn't have memory leaks in your code, right? ;)))
THE BEST tool PERIOD for memory errors, leaks, etc. is Valgrind. Get started here. You dont need to do anything special in your code and this will report where the memory was allocated (with a full stack trace, even in C). Also, it'll detect writes to freed memory, uninitialized memory usage, and much more.
Related
We have a big multi-threaded C++ application running on Linux. We see that occupied by the application memory grows fast and believe there are some leaks. We have tried every tool we have (valgrind, DynLeak, Purify) but did not find anything. Since this application can run on Windows, we have also tried Bounds Checker. Did not help, too.
We need a new tool that can help. I've looked at Google Perfomrance Tools, MMGR by Paul Nettle, MemCheck Deluxe. None of them impressed me.
Is there anywhere a good tool for this task?
The definition of a memory leak in C/C++ is very specific: it is memory that has been allocated and then the pointer was overwritten or otherwise lost. Valgrind generally detects such cases out of the box, but things are not always that simple.
Your application could very well be still using that memory. In that case you might have what a Java programmer would consider a leak, e.g. entering data in a structure and rarely (or never) removing entries.
You might be measuring the memory usage of your memory incorrectly. On Linux memory usage measurements are not as straight-forward as they seem. How have you measured your memory usage?
You should consider using the application hooks (Valgrind calls them client requests) of whatever memory analysis tool your are using, to avoid the issue with reports only being issued at program termination. Using those hooks might help you pin-point the location of your leak.
You should try using a heap profiler, such as massif from Valgrind, to look for memory allocation locations with inordinate amounts of allocated memory.
Make sure you are not using a custom allocator or garbage collector in your application. As far as I know, no memory analysis tool will work with a custom allocator without user interference.
If your memory leak is massive enough to be detectable within an acceptable amount of application run-time, you could try a binary search of old revisions through your version control system to identify the commit that introduced the problem. At least Mercurial
and Git offer built-in support for this task.
If by "did not help" you mean it did not report memory leaks, it is quite possible you don't have one and just use more and more memory that is still referenced by pointers and can be deleted.
To help you debug the problem, perhaps in your logging, you should also write memory size, number of objects (their type) and a few other stats which are useful to you. At least until you become more familiar with the tools you mentioned.
I have developed a library with Qt/C++ and now I want to sure about memory leak testing,
I found Valgrind and seems a good detector(I still don't work with it), but is there another tool(s) for testing for memory leak?
Yes, as Als has pointed out in a comment and from my personal experience, I would also recommend going with valgrind. There are various options such as --leak-check=yes etc. that you might use. Once you run valgrind, it outputs some recommend options that you can include in the next run.
The problem Valgrind is attempting, i.e., of finding memory leaks, is a complex problem. Sometimes valgrind gets confused and outputs false positives, i.e., it shows a memory leak at a place where there is none. But, other than this, valgrind is quite user-friendly and useful.
You could do the memory leak check yourself without much additional affort (depending on your code). Just provide your own versions of the operators new and delete. Use a container to store each memory address that is assigned within new. Remove it from the collection if delete is called. At the end of your program, check if the collection is empty.
Details can be e.g. found in Scott Meyers book Effective C++, Item 50.
I believe I have a double delete and some memory corruption happening somehow in my complex c++ application on OpenBSD. I would like to track down the first location my object is deleted, and any points at which deallocated memory is accessed.
I would usually look into valgrind, but it is linux only. Failing that, I would instrument my new and delete operators with some kind of tracking code, but I've been finding it difficult to determine the correct google search for this.
Is there any package for openbsd which will give me information on memory errors? Is there any kind of standard way to redefine new and delete to detect overflows, invalid accesses, double frees?
This helps a lot:
man malloc
Debugging options can be enabled system-wide, environment-wide, or program-specific.
I don't know if you are willing to use a third party tool, but C++ memory validator is very good.
http://www.softwareverify.com/cpp-memory.php
It isolates the memory/ handle leaks, tells you how much memory is leaked and shows you the position in the code. If only it could then fix the leak for you : ) 30 day free trial is available too.
I've used it to find leaks in my legacy C++ MFC application where the previous developer didn't seem to think there was a need to relase memory ever!
I have a C++ application that has some minimal leaks, and I would like to fix them. I am using AppVerifier to dump the leaked objects, and I can get the addresses and first few bytes of the allocated memory.
Unfortunately, those first bytes and raw address is not enough to pinpoint the allocation stack trace, is there a method to get complete allocation data dump, and find the stack that's allocating the memory?
I could put _CrtSetBreakAlloc via the leak number, but unfortunatelly it's a threaded application and those numbers float up and down.
Does anyone have a suggestion what I could try?
With the gflags utility you can enable storing call stack information (gflags +ust). However, your applications will now run slower and take more memory.
Side-remark: To be honest, I never got all those Microsoft utilities (leak-tracing in the C-RunTime, Gflags, UMDH, AppVerifier, LeakDiag) to do exactly what I wanted. In the end, I simply wrote my own memory allocator in which I can add whatever tracing I want (call stack, red zone marking, delayed freeing, consistency checking, ...).
You could try using UMDH to track memory leaks. You first have to use GFlags to turn on storing call stack tracing whenever memory is allocated. The docs on UMDH state how to use it.
But recently I've finally tried out visual leak detector, and it works fabulous on my monstrous, big app.
http://vld.codeplex.com
Good afternoon all,
What I'm trying to accomplish: I'd like to implement an extension to a C++ unit test fixture to detect if the test allocates memory and doesn't free it. My idea was to record allocation levels or free memory levels before and after the test. If they don't match then you're leaking memory.
What I've tried so far: I've written a routine to read /proc/self/stat to get the vm size and resident set size. Resident set size seems like what I need but it's obviously not right. It changes between successive calls to the function with no memory allocation. I believe it's returning the cached memory used not what's allocated. It also changes in 4k increments so it's too coarse to be of any real use.
I can get the stack size by allocating a local and saving it's address. Are there any problems with doing this?
Is there a way to get real free or allocated memory on linux?
Thanks
Your best bet may actually be to use a tool specifically designed for the job of finding memory leaks. I have personal experience with Electric Fence, which is easy to use and seems to do the job nicely (not sure how well it will handle C++). Also recommended by others is Dmalloc.
For sure though, everyone seems to like Valgrind, which can do just about anything and even has front-ends (though anything that has a front-end built for it means that it probably isn't the simplest thing in the world). If the KDE folks can recommend it, it must be able to handle just about anything. (I'm not saying anything bad about KDE, just that it is a very large C++ codebase, so if Valgrind can handle KDE software, it must have something going for it. Though I don't have personal experience with it as Electric Fence was always enough for me)
I'd have to agree with those suggesting Valgrind and similar, but if the run-time overhead is too great, one option may be to use mallinfo() call to retrieve statistics on currently allocated memory, and check whether uordblks is nonzero.
Note that this will have to be run before global destructors are called - so if you have any allocations that are cleaned up there, this will register a false positive. It also won't tell you where the allocation is made - but it's a good first pass to figure out which test cases need work.
don't look a the OS to get allocation info. the C library manages memory internally, and only asks the OS for more RAM in chunks (4KB in your case). In most cases, it's never released to back to the OS, so you can't really check anything there.
You'll have to patch malloc() and free() to get the info you need.
Or, use Valgrind.
Not a direct answer but you could re-define the ::new and ::delete operators, and internally either via a singleton or global objects, keep track of the allocated, and de-allocated memory.
Edit: If this is a personal, DIY project then cool. But if its for something critical you can always jump onto one of the many leak detection libraries/programs available, a quick google search should suffice.
google-perftools can be used in your test code.