Measure static, heap and stack memory ? (c++, Linux - Centos 7)

问题

I would like to measure stack, heap and static memory separately because I have some constraints for each one.

To measure the heap memory I'm using valgrind->massif tool. Massif should also be possible to measure heap AND stack memory but it shows strange resultats :

Last snapshot without --stacks=yes provides total(B)=0, useful-heap(B)=0, extra-heap(B)=0 (so all is fine)
Last snapshot with --stacks=yes provides total(B)= 2,256, useful-heap(B)=1,040, extra-heap(B)=0, stacks(B)=1,208 (which shows memory leak even if it is the same command and same binary tested... dunno why ...)

So finally I need a tool to measure stack and static memory used by a c++ binary, some help would be welcome :)

Thanks for your help !

----------- EDIT --------------

Further to the Basile Starynkevitch comment, to explain what I mean with static, stack and heap memory I took it from the Dmalloc library documentation :

Static data is the information whose storage space is compiled into the program.

/* global variables are allocated as static data */
int numbers[10];

main()
{
        …
}

Stack data is data allocated at runtime to hold information used inside of functions. This data is managed by the system in the space called stack space.

void foo()
{
        /* if they are, the parameters of the function are stored in the stack */
        /* this local variable is stored on the stack */
        float total;
        …
}

main()
{
    foo();
}

Heap data is also allocated at runtime and provides a programmer with dynamic memory capabilities.

main()
{
    /* the address is stored on the stack */
    char * string;
    …

    /*
     * Allocate a string of 10 bytes on the heap.  Store the
     * address in string which is on the stack.
     */
    string = (char *)malloc(10);
    …

    /* de-allocate the heap memory now that we're done with it */
    (void)free(string);
    …
}

回答1:

I would like to measure stack, heap and static memory separately because I have some constraints for each one.

I cannot imagine why you have separate constraints for each one. They all sit in virtual memory! BTW you might use setrlimit(2) to set limits (perhaps from the invoking shell process, e.g. with bash ulimit builtin).

Your definitions are naive, if you consider the actual virtual address space of your process.

BTW, proc(5) enables you to query that space, e.g. using /proc/self/maps like here from inside your program (or /proc/1234/maps to query the process of pid 1234, perhaps from a terminal). You could also use /proc/self/status and /proc/self/statm (BTW try cat /proc/self/maps and cat /proc/$$/maps in a terminal). On Linux, you might also use mallinfo(3) and malloc_stats(3) to get information about memory allocation statistics.

Static data may be in the data segment (or BSS segment) of your program. But what about thread local space? And these data segments also contain data internal to various libraries, notably the C standard library libc.so (do that count?). Of course the stack segment is often bigger (since page aligned) than the actual used stack (from "bottom" to current %esp register). And a multi-threaded process has several stacks (and stack segments), one per thread.

Stack data is of course in the call stack, which contains a lot of other things (return addresses, gap, spilled registers) than just automatic variables (some of them sitting only in registers or being optimized by the compiler, without consuming any stack slot). Do they count? Also, startup code from crt0 (which calls your main) is likely to use a little bit of stack space (does it count?)...

Heap allocated data (it could be allocated from various libraries, or even from the dynamic linker) contains not only what your program gets from malloc (and friends) but also the necessary overhead. Do that count? And what about memory-mapped files? How should they count?

I would recommend querying the actual virtual address space (e.g. by reading /proc/self/maps or using pmap(1)...) but they you get something different than what you ask.