This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11087] mallinfo miscounting hblks because of missing mutex
- From: "stef dot van-vlierberghe at telenet dot be" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 10 Apr 2010 12:33:38 -0000
- Subject: [Bug libc/11087] mallinfo miscounting hblks because of missing mutex
- References: <20091214085632.11087.stef.van-vlierberghe@telenet.be>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From stef dot van-vlierberghe at telenet dot be 2010-04-10 12:33 -------
I'm running 32 bit so I have at present no problem with mallinfo API, so not
understood why it would be classified as "broken". Anyway changing to new API is
only minor "damage" in the sense that we have no need for fork/exec activity or
creating files for heap statistic collection (context of use is the European
flow management and flight planning systems that run on Linux since a month, see
www.eurocontrol.int). In this context (and I can imagine many others) correct
stats are worth one pthread lock operation for each large block malloc (which is
a rare event in these processes, doesn't occur at all in several critical
processes), so the "too expensive" is also not clear, unless if it means too
expensive in terms of validating/testing. In that case I would appreciate if you
could clarify what precisely is required to get precise statistics using glibc
malloc ? (I validated the fix using the test as described before, if you require
additional measurements or tests please clarify).
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
http://sourceware.org/bugzilla/show_bug.cgi?id=11087
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.