Is mallinfo implemented correctly?

[GoogleCodeExporter]

# 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]

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]

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]

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]

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]

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]

No more word, so closing the bug.

Original comment by csilv...@gmail.com on 30 Oct 2010 at 12:16

• Changed state: CannotReproduce