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:
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.
Then which function we should use in our 64bit application that can give correct results for >2GB. Please help us in this regard.
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
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.
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.
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.
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
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.