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: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
