top shows much less memory(500mb) but tmalloc shows cumulative memory as 2000mb for my process

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Trying to understand the difference between what is reported by tmalloc and 
top output on linux
2.
3.

What is the expected output? What do you see instead?
i thought there should be at least some correlation between the memory usage 
reported by top and tmalloc or they should be pretty close

What version of the product are you using? On what operating system?
tmalloc from gperftools-2.0

Please provide any additional information below.

Original issue reported on code.google.com by krmay...@gmail.com on 12 Sep 2014 at 7:00

[GoogleCodeExporter]

Please attach output of MallocExtension::GetStats. I need to know what exact 
metric 2000mb is.

Original comment by alkondratenko on 12 Sep 2014 at 8:13

[GoogleCodeExporter]

i dont link to this library but LD_PRELOAD it. I am talking about the following 
output when heap profiling is on:-
Dumping heap profile to /tmp/abc.0043.heap (2050 MB allocated cumulatively, 167 
MB currently in use). Here 2050 MB allocated cumlatively is way off then what i 
see in output of top command which shows VIRT, RES and SHR as 500m, 326m and 
50m. Also eventually probably because of a leak in my program kernel oom kills 
my process with the following output:-

%KERN-1-SYSTEM_MSG: [49326.103001] Proc xyz (15511) with Total_VM 594236 KB 
Resident_Mem 87991 KB Anon_Resident_Mem 87615 KB being killed due to lack of 
memory  - kernel

when tcmalloc in the very end reported the following:-
Dumping heap profile to /tmp/abc.0055.heap (2623 MB allocated cumulatively, 231 
MB currently in use)

So why this different, where is 2623 mb allocation value coming from ?

Original comment by krmay...@gmail.com on 12 Sep 2014 at 8:59

[GoogleCodeExporter]

Misunderstanding appears to be due to not paying attention to "cumulative" in 
this message.

It really means cumulative. I.e. it is sizes of all memory allocations ever 
made added together.

Original comment by alkondratenko on 14 Sep 2014 at 8:07

• Changed state: NotABug

[GoogleCodeExporter]

Great thanks for your help. I am just beginning to use this great tool. Few 
question, i am guessing you can help answer:-
-So cumulative means all memory ever allocated by the process(using free/new) 
including the memory which is already free. Please confirm ?
-231mb currently in use. This is allocated using malloc/new but not yet freed ? 
Please confirm

-i am trying to find memory leaks using the following command,
pprof) Linux(debug)# /tmp/pprof /isan/bin/abc --base abc.0080.heap 
abc.0090.heap. and it reports the following:-
(pprof) top
Total: 3.3 MB
     0.6  19.7%  19.7%      0.6  19.7% _ZN7adaptor18EthPortStatsHistMo7factoryEN2mo11FactoryTypeE
     0.5  13.7%  33.3%      0.5  13.7% _ZN7adaptor23EthPortMcastStatsHistMo7factoryEN2mo11FactoryTypeE

A couple of questions about this:-
a: Is this a good way to detect leaks?
b: is the Total reported here the extra malloc's done from the base which were 
not freed yet
c: i get the above output which  doesnt display the proper stack. is there a 
way i can get the complete stack where the extra malloc happened ?

PS: if you think there is a better forum i should go please let me know.

Original comment by krmay...@gmail.com on 15 Sep 2014 at 6:38

[GoogleCodeExporter]

>> -So cumulative means all memory ever allocated by the process(using 
free/new) including the memory which is already free. Please confirm ?

Yes.

>> -231mb currently in use. This is allocated using malloc/new but not yet 
freed ? Please confirm

Yes

Original comment by alkondratenko on 20 Sep 2014 at 11:20

[GoogleCodeExporter]

>> a: Is this a good way to detect leaks?

Yes. As pointed out in the docs.

>> b: is the Total reported here the extra malloc's done from the base which 
were not freed yet

Yes.

>> c: i get the above output which  doesnt display the proper stack. is there a 
way i can get the complete stack where the extra malloc happened ?

--web may give you that information

Original comment by alkondratenko on 20 Sep 2014 at 11:29