> I imagine that this indicates that control-C processing allocates some
> memory it doesn't free, resulting in an "island" up at the end of memory
> that prevents glibc from releasing all the free memory it's got. Whether
> that's an actual leak, or just memory we're holding onto in hopes of
> reusing it, isn't clear. (valgrind might be useful.)
malloc could request memory from kernel by two ways: sbrk() and mmap(),
first one has described problem, mmap hasn't. It's described in
mallopt(3) in section M_MMAP_THRESHOLD, to test that try to repeat test
with MALLOC_MMAP_THRESHOLD_ environment set to 8192.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
