Bug 173813 - mallinfo returns wrong value for >4GB usage
mallinfo returns wrong value for >4GB usage
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-21 10:20 EST by Rajdeep Sengupta
Modified: 2016-11-24 11:13 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-22 14:07:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rajdeep Sengupta 2005-11-21 10:20:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Description of problem:
When we use mallinfo function under malloc.h for 32bit rhel3 it works fine but when we use it in rhel X86_64bit, then upto 4GB it returns correctly, but when the memory usage increase to more than 4GB, it returns garbage value because of overflow. This is because the mallinfo define in malloc.h uses "int" as define type, whereas "long int" is required to give correct value.
So does RHEL 3 for X86_64bit has any other function (for 64bit) which can be used to get the memeory usage by an application.
--------------------------------------------------------
struct mallinfo {
   int arena;    /* non-mmapped space allocated from system */
   int ordblks;  /* number of free chunks */
   int smblks;   /* number of fastbin blocks */
   int hblks;    /* number of mmapped regions */
   int hblkhd;   /* space in mmapped regions */
   int usmblks;  /* maximum total allocated space */
   int fsmblks;  /* space available in freed fastbin blocks */
   int uordblks; /* total allocated space */
   int fordblks; /* total free space */
   int keepcost; /* top-most, releasable (via malloc_trim) space */ };

unsigned long sysUtilGetMallocMemory(void) {
     struct mallinfo m;
     m = mallinfo();
     return (unsigned int)(m.uordblks + m.hblkhd); }

Please check that we rely on two fields of "mallinfo" struct - uordblks & hblkhd, and both these fields are defined as "int" type in "malloc.h".



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Use mallinfo function in your application
2. The application should try to allocate/usr more than 4GB memory
3. Check the return value of mallinfo, because of overflow it will give wrong value

  

Additional info:
Comment 1 Jakub Jelinek 2005-11-21 10:27:21 EST
Mallinfo is badly designed interface that is provided just for compatibility,
it doesn't correspond very well with the malloc implementation used in glibc
(multiple arenas etc.).
No new app should use it, it won't be extended to handle > 2GB sizes on 64-bit
arches nor for multiple arenas.
Comment 2 Rajdeep Sengupta 2005-11-21 10:39:24 EST
Then which function we should use in our 64bit application that can give 
correct results for >2GB. 
Please help us in this regard.
Comment 3 Rajdeep Sengupta 2005-11-22 05:33:33 EST
Then which function we should use in our 64bit application that can give 
correct results for >2GB. 
Please help us in this regard.

Comment 4 Jakub Jelinek 2005-11-22 05:48:28 EST
Please define "correct result".  Depends on what exact information you are
looking on.  mallinfo interface can give you just very limited info mapped
onto old SVID2 interface that corresponded to completely different malloc
implementation.
There is malloc_stats () routine that prints some glibc malloc specific info
to stderr.
Eventually a new API to query statistics should be added, but there hasn't
been much feedback about it.
For details, see
http://sources.redhat.com/ml/libc-alpha/2004-08/msg00155.html
Comment 5 Rajdeep Sengupta 2005-11-22 06:05:55 EST
We need a PI which can report memory currently used by a given process. For
example..
Consider an application which allocates maximum 5GB of memory during runtime, so
the peak memeory used is 5GB, this data can be captured from vmdata under /proc.
But say the same application then frees 500MB of memory, so the vmdata will
still show 5GB (peak memory), but actually at runtime it is now using 4.5GB. Now
if we use mallinfo PI, then it will return only 500MB because of overflow.
So we need a PI which can report exact memory allocated at runtime.
Comment 6 Rajdeep Sengupta 2005-11-22 06:08:08 EST
We need a PI which can report memory currently used by a given process. For
example..
Consider a process which allocates maximum 5GB of memory during runtime, so the
peak memeory used is 5GB, this data can be captured from vmdata under /proc.
But say the same application then frees 500MB of memory, the vmdata will still
show 5GB (because it captures peak memory only), but  at runtime it is now using
4.5GB instead. Now if we use mallinfo PI or function, then it will return only
500MB instead of 4.5GB because of overflow.
So we need a PI which can report exact memory allocated during runtime.
Comment 7 Ulrich Drepper 2005-11-22 09:11:17 EST
There is no reliable interface and none will appear in the RHEL4 lifetime. 
There is not even one in the upstream glibc.

It is always possible for somebody to write a DSO which is interposed with
LD_PRELOAD which keeps track of the memory usage.  Or simply add such functions
to the main executable and link with -rdynamic.  This is pretty easy to do and
can be absolutely reliable.  It does not need any support from the libc.
Comment 8 Rajdeep Sengupta 2006-02-01 09:57:41 EST
Please send us a sample DSO which we can use to overload and keep track of 
memory usage in runtime.
or can  you give us an example as we could not understand the second part
Comment 9 Jakub Jelinek 2006-02-22 14:07:52 EST
You can write it yourself.  Just intercept malloc/free/realloc/calloc/etc.
calls and through dlsym (RTLD_NEXT, "malloc") etc. use the libc ones
in it.  For examples how that can be done see e.g. ElectricFence, dmalloc or
njamd.

Note You need to log in before you can comment on or make changes to this bug.