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
Related
I'm working with embedded linux development, and we're currently having some trouble with some memory page allocation faults, which led me to believe we have a leak somewhere.
Currently, I am trying to cross compile valgrind to use on our system, but I'm losing my faith on this solution because of the sheer amount of memory valgrind will use up (we have serious memory restrictions).
This has made me wonder: is there any way of hunting for a memory leak without valgrind or with a valgrind-like application with minimal memory usage? Creating wrappers for malloc() and free() is out of question.
Also, the test that caused the allocation failures was a simple stress test of copying a file n times and checking its md5sum, in case anyone is curious.
I'm using the Linaro toolchain for cross compiling, glibc 2.15, and the system is set up without a swap partition. The system has around 64MB of RAM, making valgrind, or any other memory intensive application a tad difficult to use.
Regards,
Guilherme
Since you are using glibc, you should have its built-in memory-tracing support available to you. Your program would enable this by calling mtrace(3) at or near startup. mtrace() installs hook functions into the memory allocator to log allocations and deallocations, under runtime control via environment variable MALLOC_TRACE.
You probably also want to be aware of mtrace(1), a Perl script for interpreting log files produced by the mtrace facility.
This facility traces only allocations and deallocations, which is much less than Valgrind does. Nevertheless, those are the main items of interest when you are looking for a memory leak.
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...
I have a C program which contains many memory allocation even from external libraries and I want to check periodically the total allocated memory by my application (library allocations included).
I tried with some linux commands like ps euf, pmap $pid, cat /proc/$pid/status but without any real results.
I make some research and I found the adequate tool todo that is with valgrind.
I tried to dump the memory when my application is running with:
valgrind --tool=drd --trace-alloc=yes
But I did not get result like the result displayed by valgrind at the end of execution.
How to make valgrind displaying the memory status (like the result displayed by valgrind at the end of execution) when my application is running?
According to the 3.8.0 valgrind manual, there is no such option for the core or for memcheck, and no mention on periodic or triggered behaviour in the signal section. valgrind can't do it out of the box.
While you might write a valgrind tool to do the job, you might re-think the approach and clarify what kind of memory usage you want, and if the system statistics might be sufficient for your task.
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~~~
HI, i am recently in a project in linux written in C.
This app has several processes and they share a block of shared memory...When the app run for about several hrs, a process collapsed without any footprints so it's very diffficult to know what the problem was or where i can start to review the codes....
well, it could be memory overflown or pointer malused...but i dunno exactly...
Do you have any tools or any methods to detect the problems...
It will very appreciated if it get resolved. thanx for your advice...
Before you start the program, enable core dumps:
ulimit -c unlimited
(and make sure the working directory of the process is writeable by the process)
After the process crashes, it should leave behind a core file, which you can then examine with gdb:
gdb /some/bin/executable core
Alternatively, you can run the process under gdb when you start it - gdb will wake up when the process crashes.
You could also run gdb in gdb-many-windows if you are running emacs. which give you better debugging options that lets you examine things like the stack, etc. This is much like Visual Studio IDE.
Here is a useful link
http://emacs-fu.blogspot.com/2009/02/fancy-debugging-with-gdb.html
Valgrind is where you need to go next. Chances are that you have a memory misuse problem which is benign -- until it isn't. Run the programs under valgrind and see what it says.
I agree with bmargulies -- Valgrind is absolutely the best tool out there to automatically detect incorrect memory usage. Almost all Linux distributions should have it, so just emerge valgrind or apt-get install valgrind or whatever your distro uses.
However, Valgrind is hardly the least cryptic thing in existence, and it usually only helps you tell where the program eventually ended up accessing memory incorrectly -- if you stored an incorrect array index in a variable and then accessed it later, then you will still have to figure that out. Especially when paired with a powerful debugger like GDB, however (the backtrace or bt command is your friend), Valgrind is an incredibly useful tool.
Just remember to compile with the -g flag (if you are using GCC, at least), or Valgrind and GDB will not be able to tell you where in the source the memory abuse occurred.