Is mallinfo implemented correctly?
GoogleCodeExporter opened this issue · 6 comments
GoogleCodeExporter commented
# What steps will reproduce the problem?
1. Start an application
2. Run mallinfo()
3. Free some memory
4. Run mallinfo()
5. Compare the results
# What is the expected output? What do you see instead?
I expected the uordblks to be lower after freeing some memory. The two
results are:
MEMORY INFO: arena=202358784 ordblks= 0 smblks= 0 hblks= 0
hblkhd= 0 usmblks= 0 fsmblks=1313056 uordblks=96118496
fordblks=104927232 keepcost= 0
MEMORY INFO: arena=202358784 ordblks= 0 smblks= 0 hblks= 0
hblkhd= 0 usmblks= 0 fsmblks=1254024 uordblks=96423288
fordblks=104681472 keepcost= 0
# How can I obtain the information about how many memory is used by
tcmalloc and actually given to the application?
What version of the product are you using? On what operating system?
CentOS release 5.2 (Final)
google-perftools-1.3-1
Original issue reported on code.google.com by gilvan...@gmail.com
on 16 Mar 2010 at 3:10
GoogleCodeExporter commented
Your last question is easier to answer: you can use MallocExtension::instance()-
>GetStats(). This shows usage statistics in a way that's customized to how
tcmalloc
manages memory. The mapping from tcmalloc's model to mallinfo's model is a
little
lossy.
Here is how mallinfo is computed (from the tcmalloc source):
---
info.arena = static_cast<int>(stats.pageheap.system_bytes);
info.fsmblks = static_cast<int>(stats.thread_bytes
+ stats.central_bytes
+ stats.transfer_bytes);
info.fordblks = static_cast<int>(stats.pageheap.free_bytes +
stats.pageheap.unmapped_bytes);
info.uordblks = static_cast<int>(stats.pageheap.system_bytes
- stats.thread_bytes
- stats.central_bytes
- stats.transfer_bytes
- stats.pageheap.free_bytes
- stats.pageheap.unmapped_bytes);
---
GetStats should give you each of these individual numbers, so you can look at
that
and see how it maps to the mallinfo numbers, and whether that meets your
expectations. If not, explain which numbers in particular are acting
differently
than you expect, and we'll see if we can figure out what's going on.
Original comment by csilv...@gmail.com
on 16 Mar 2010 at 7:29
- Added labels: Priority-Medium, Type-Defect
GoogleCodeExporter commented
Isn't this a problem on x86_64, that the values are given as int and not
size_t?
Original comment by gilvan...@gmail.com
on 6 Apr 2010 at 7:22
GoogleCodeExporter commented
Sure seems like it, no? But struct mallinfo consists of ints, at least on my
system
(gcc 4.2.4). (On solaris, on the other hand, they're unsigned longs.)
As http://kobesearch.cpan.org/htdocs/Devel-Mallinfo/Devel/Mallinfo.pm.html says:
"On a 64-bit system with a 32-bit C int type, the int fields in struct mallinfo
may
overflow and either wrap around to small or negative values, or hopefully cap
at
INT_MAX. This is a known C library problem and Devel::Mallinfo doesn't try to
do
anything about it."
In any case, that doesn't seem to be the problem here.
Original comment by csilv...@gmail.com
on 6 Apr 2010 at 5:32
GoogleCodeExporter commented
Any more word on this? Having the GetStats info would be very helpful to
figuring out what's going on here.
Original comment by csilv...@gmail.com
on 7 Jun 2010 at 11:05
GoogleCodeExporter commented
Let me know if you have any more info, or I'll have to close the bug
CannotReplicate.
Original comment by csilv...@gmail.com
on 2 Aug 2010 at 4:34
GoogleCodeExporter commented
No more word, so closing the bug.
Original comment by csilv...@gmail.com
on 30 Oct 2010 at 12:16
- Changed state: CannotReproduce