linux - Ubuntu System Monitor and valgrind to discover memory leaks in C++ applications -
i'm writing application in c++ uses external open source libraries. tried @ ubuntu system monitor have information how process uses resources, , noticed resident memory continues increase large values (over 100mib). application should run in embedded device, have careful.
i started think there should (some) memory leak(s), i'm using valgrind. unfortunately seems valgrind not reporting significant memory leaks, minor issues in libraries i'm using, nothing more.
so, have conclude algorithm uses memory? seems strange me... or maybe i'm misunderstanding meaning of columns of system monitor? can clarify meaning of "virtual memory", "resident memory", "writable memory" , "memory" in system monitor when related software profiling? should expect values represent how memory process taking in ram?
in past i've used tools able tell me using memory, apple profiling tools. there similar can use in linux well?
thanks!
another tool can try /lib/libmemusage.so
library:
$ ld_preload=/lib/libmemusage.so vim memory usage summary: heap total: 4643025, heap peak: 997580, stack peak: 26160 total calls total memory failed calls malloc| 42346 4528378 0 realloc| 52 7988 0 (nomove:26, dec:0, free:0) calloc| 34 106659 0 free| 28622 3720100 histogram block sizes: 0-15 14226 33% ================================================== 16-31 8618 20% ============================== 32-47 1433 3% ===== 48-63 4174 9% ============== 64-79 4736 11% ================ 80-95 313 <1% = ...
(i quit vim
after startup.)
maybe histogram of block sizes give enough information tell leaks may happening.
valgrind
configurable; --leak-check=full --show-reachable=yes
might starting point, if haven't tried yet.
"virtual memory", "resident memory", "writable memory" , "memory"
virtual memory address space application has allocated. if run malloc(1024*1024*100);
, malloc(3)
library function request 100 megabytes of storage operating system (or handle out of free lists). 100 megabytes allocated mmap(..., map_anonymous)
, which won't allocate memory. (see rant @ end of malloc(3)
page details.) os provide memory first time each page written.
virtual memory accounts libraries , executable objects mapped process, stack space.
resident memory amount of memory in ram. might link against entire 1.5 megabyte c library, use 100k (wild guess) of library required support standard io interface. rest of library demand paged in disk when needed. or, if system under memory pressure , less-recently-used data paged out swap, no longer count against resident memory.
writable memory amount of address space process has allocated write privileges. (check output of pmap(1)
command: pmap $$
shell, example, see pages mapped files, anonymous space, stack, , privileges on pages.) reasonable indication of how swap space program might require in worst-case swapping scenario, when must paged disk, or how memory process using for itself.
because there 50--100 processes on system @ time, , of them linked against standard c library, processes share read-only memory mappings library. (they share copy-on-write private writable mappings files opened mmap(..., map_private|prot_write)
, until process writes memory.) top(1)
tool report amount of memory can shared among processes in shr
column. (note memory might not shared, of (libc
) shared.)
memory vague. don't know means.
Comments
Post a Comment