This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/21731] Bad malloc heuristic result in 30-40x memory consumption


https://sourceware.org/bugzilla/show_bug.cgi?id=21731

--- Comment #14 from Yichao Yu <yyc1992 at gmail dot com> ---
> Where is the memory going?

Where is what memory going.

The small actual allocation can be treated as "program requirements growing
with time?" for all purpose in this report. The large growth in overall
consumption (measured by overall system memory usage and also the maxrss of the
process) is exactly what this bug report is about.

> It is not a trivial analysis.

I agree, and thanks for the pointer to the branches/tools, I will try those.

> Again your example is a bad one to try show any point. As from my comment #6 RSS at end of execution is roughly 61MB and valgrind is showing a memory leak of 54MB. This is hardly '10x' increase and it shows more an issue of the workload/example than on GLIBC.

I agree and I've already acknowledged that the code I attached does not seem to
reproduce the original issue, which does have a effect on actual memory
consumption measured with multiple ways.

> I think you might not be clear here and using 'memory consumption' as virtual memory increase.

No. I think I might not be clear enough when I switched from talking about the
behavior of the simplified program, which doesn't show increase in rss, to
talking about the actual program, which does. And I'm now basically asking for
help to figure out what's missing to reproduce it.

> GLIBC memory allocation will try to coalesce memory on newer allocations, but fragmentation might impede and thus why the increase of virtual memory allocation (some information on the algorithm used can be found at section 'Malloc Algorithm' [1]).

So I guess I might be able to find this info out by reading the link in the
previous comment but is there a simple way to dump the heap map? Last time I
check it's consistent with glibc leaving the big hole unfilled but it'll be
nice if I can verify that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]