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/