Bug 173813
Summary: | mallinfo returns wrong value for >4GB usage | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Rajdeep Sengupta <rajdeep> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | drepper, fweimer, jsarenik |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-22 19:07:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rajdeep Sengupta
2005-11-21 15:20:51 UTC
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. 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. |