I am developing a statically-linked 64-bit C++ application on 64-bit CentOS 5.8 using the standard gcc 4.4 packages from the CentOS repositories. It appears to be using more memory than I expected, so I tried using massif to profile the memory usage. I have compiled with debug information and then run
valgrind --tool=massif ./MyProg
from the directory where MyProg resides. It never produces any results other than the following massif.out.XXXX example.
desc: (none)
cmd: ./MyProg
time_unit: i
#-----------
snapshot=0
#-----------
time=0
mem_heap_B=0
mem_heap_extra_B=0
mem_stacks_B=0
heap_tree=empty
Note that that is the entire contents of the file and my program can run for many minutes.
I have tried various options to valgrind and massif to no avail. I even tried using the absolute path to MyProg, just in case. I've tried downloading the most recent stable version of valgrind (3.8.1) and compiling and running that (since CentOS is using 3.5.0) with the same result. As a sanity check I ran
valgrind --tool=massif ls -l
and it produced multiple snapshots with non-zero memory usage as expected.
I've tried searching online using every combination of keywords I could think of but did not find any similar problems.
As a side note, I can successfully profile the application using valgrind's default memcheck tool, in case that is useful information.
Does anyone know why massif would fail to profile my application?
If the application is statically linked, it cannot be analyzed using valgrind. Valgrind works by providing it's own version of the allocation functions to your program, which it accomplishes by overriding the dynamic lookup.
If you can dynamically link with the standard libraries (libc and libstdc++), then it should probably be able to perform the memory analysis you're looking for.
From the Valgrind FAQ:
Second, if your program is statically linked, most Valgrind tools won't work as well, because they won't be able to replace certain functions, such as malloc, with their own versions.