I am working on VxWorks target board. I want to make sure that my application or driver does not have any memory leak.
Is there any specific way so that I can check memory leak at run time
or without running the application?
You need MemScope provided by Wind River which is compatible with vxworks also refer http://borkhuis.home.xs4all.nl/vxworks/vxw_pt6.html#6.2
Although it is inaccurate you can use the memShow command on the VxWorks shell.
To check for memory leaks do a "base line" after your application has started. Then run your tests or stimulate your application or simply let it run for a few hours. After that check the outputs of memShow again. If the values have changed "dramatically" you have a problem.
Notes:
This is very basic and just helps you to know that you actually have a memory leak. It does not show you which thread, or function...
Remeber that this function shows the total available memory (not only to your application). So some changes are normal due to VxWorks operating...
Related
I am developing a shared memory suite of applications, in C, on Ubuntu 12.04 server.
This is my first attempt at dealing with shared memory, so I am not sure of all the pitfalls.
My suite starts with a daemon that creates a shared memory segment, and a few other apps that use it.
During development, of course, the segment can get created, then the program crash without removing it. I can see it listed using ipcs -m.
Normally, this isn't much of an issue, as the next time I start the "controlling" program, it simply reuses the existing segment.
However, from time to time, the size of the segment changes, so the program fails the shmget() function.
My question...
Before I create and attach the segment, I would like to first determine if it already exists, then if needed, unattach it, then I think, shmctl(..., ipc_rmd, ...).
Can I have some help to figure the proper sequence of events to do this?
I think I should use shmctl to see what's up, (number of attachments, if it exists, etc..) but I don't really know.
It may be there is another app still using the segment, of course that app will have to first be stopped, and any other possible exceptions handled.
I was thinking, in the shared memory segment, I could copy the system clock, and when the app detects the clock of the shared mem differs more then a few seconds, then detach or something.
Thanks, Mark.
I am developping a multithreaded application which seems to allocate huge amounts of memory during its runtiime. All the memory gets freed in the end of execution, so valgrind shows no memory leaks. I tried to use massif tool to find out what was happening, but ms_print seems to show information only about the main thread. However, I believe that the great majority of memory is allocated in child threads. Is it possible to make massif show information about them?
For me (Ubuntu 12.04), this seems to work by default. Like in your application, my main thread doesn't do much of anything (except handling my gtk-based UI), and all the (de)allocating is done in subthreads.
I did have some initial difficulty because I am analysing an autotools-based project, and in my first attempts I was analyzing a shell-script generated by libtool, instead of my application.
You can set --trace-children=yes [default:no]
When enabled, Valgrind will trace into sub-processes initiated via the exec system call. This is necessary for multi-process programs.
massif manual
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.
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.