mallinfo in Linux for heap size
Guanglei
I want to know how big the heap size is from some places of my
program. In AIX I used mallinfo(). But in Linux, I tried 'man
mallinfo' but returned no result. I tried to compile my program in
Linux, it passed, but mallinfo() just return a structure mallinfo of
all zero. I googled and found mallinfo did exist at least in previous
old Linux. So is currently mallinfo() obsolete from Linux? If so, what
else library calls should I use to get the current heap size?
Thanks.
Guanglei
I googled and found both mallopt/mallinfo were dropped by POSIX 2008.
So is there an equivalent of mallinfo in current Linux?
Thanks.
Shankar
I see the entry points do exist in libc.so.6 but I think they are
morely undocumented.
Thanks
Shankar K E
Rainer Weikusat
They are not. The 'real' glibc documentation is in info format and
manpages may or may not be accurate and may or may not exist[*]. The
relevant section is 3.2.2.11:
You can get information about dynamic memory allocation by calling the
`mallinfo' function. This function and its associated data type are
declared in `malloc.h'; they are an extension of the standard SVID/XPG
version.
[...]
This text should be accessible by using the 'info libc' command. NB:
This program doesn't support vi-keybindings, at least not by default.
stef
Beware of mallinfo(), I have an issue with non-atomic increment/
decrement
of hblks, (i.e. n_mmaps) in a multi-threaded mission critical process
that monitors
heap usage as part of supervision. This value can drift astray of the
true count and
rarerly triggers an assertion in the total heap calculatio. There is a
similar disabled
assert in glibc:
#ifdef NO_THREADS
assert(total <= (unsigned long)(mp_.max_total_mem));
assert(mp_.n_mmaps >= 0);
#endif
Seem to be a problem of wanting to pay the cost of mutex contention
instead of
the (application specific) cost of providing wrong values. In the
context of a malloc call
that asks for 2 Mb, I have not figured out that part yet, but I can't
imagine that keeping
a correct total count in a multi-threaded is beyond state of the art
(but am sure it may
be beyond desire of hackers or motivation of maintainers). There is a
disabled
THREAD_STATS switch but that doesn't seem to handle this case. The
problem might be
resolved, but at home I can still reproduce it with latest glibc:
with Text_Io;
with Unchecked_Deallocation;
procedure T is
type Mallinfo_Field is (Arena, Ordblks, Smblks, Hblks, Hblkhd,
Usmblks, Fsmblks, Uordblks, Fordblks, Keepcost);
type Mallinfo_Stats is array (Mallinfo_Field) of Integer;
-- on 32 bit.
function mallinfo return Mallinfo_Stats;
pragma Interface (C, mallinfo);
type Large is array (1..2**22) of Character; -- 4M
type Large_Ptr is access Large;
procedure Free is new Unchecked_Deallocation (Large, Large_Ptr);
task type Alloc is
pragma Priority (0);
end Alloc;
task body Alloc is
L : array (1..10) of Large_Ptr;
begin
for Count in Natural loop
for I in L'Range loop
L(I) := new Large;
end loop;
for I in L'Range loop
Free (L(I));
end loop;
-- To check for sufficient parallelism
-- Test on multi-core/multi-processor
if Count mod 10000 = 0 then
Text_Io.Put_Line (Count'Img);
end if;
end loop;
end;
Loads : array (1..4) of Alloc;
procedure Show_Stats is
Result : constant Mallinfo_Stats := mallinfo;
begin
for Field in Result'Range loop
Text_IO.Put (Field'Img & "=" & Result(Field)'Img & " ");
end loop;
Text_Io.New_Line;
if Result(Hblks) not in 0..40 then
for T in Loads'Range loop
abort Loads(T);
end loop;
raise Program_Error;
end if;
end Show_Stats;
begin
loop
delay 1.0;
Show_Stats;
end loop;
end;
output :
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS= 0 HBLKHD=-20992000 USMBLKS=
0 FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
22700000
22620000
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS= 17 HBLKHD= 50380800 USMBLKS=
0 FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
22630000
22570000
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS= 7 HBLKHD= 8396800 USMBLKS= 0
FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
22710000
22630000
22640000
22580000
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS= 2 HBLKHD=-12595200 USMBLKS=
0 FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
22720000
22640000
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS= 0 HBLKHD=-20992000 USMBLKS=
0 FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
22650000
22590000
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS= 26 HBLKHD= 88166400 USMBLKS=
0 FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
22730000
22650000
22660000
22600000
ARENA= 135984 ORDBLKS= 1 SMBLKS= 0 HBLKS=-1 HBLKHD=-25190400 USMBLKS=
0 FSMBLKS= 0 UORDBLKS= 62424 FORDBLKS= 73560 KEEPCOST= 73560
raised PROGRAM_ERROR : t.adb:52 explicit raise