[Bug malloc/15089] malloc_trim always trims for large padding
fernandojvdasilva at gmail dot com
sourceware-bugzilla@sourceware.org
Wed Nov 20 02:03:00 GMT 2013
https://sourceware.org/bugzilla/show_bug.cgi?id=15089
Fernando J V da Silva <fernandojvdasilva at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fernandojvdasilva at gmail dot com
--- Comment #3 from Fernando J V da Silva <fernandojvdasilva at gmail dot com> ---
I've also noticed this bug. I wrote another test program that can also
demonstrate it. In this test program one can see the memory is reduced to 4096
(1 page) when pad = MAX_SIZET, which shouldn't happen according to
malloc_trim's docs, as previously stated by Thiago Ize. The problem seems to
happen when pad is any value that would be negative when implicitly cast to
long inside systrim "extra" variable calculation. So if someone changes this
program to assign a smaller value to pad -- say pad = MAX_SIZET / 2 -- then the
problem doesn't happen since the heap is kept the same after calling
malloc_trim, as expected.
#include <stdio.h>
#include <malloc.h>
#define MAX_SIZET (~(size_t)0)
int main(int argc, char **argv)
{
char *p1;
size_t pad;
printf("Allocating 100k\n");
p1 = malloc(100000);
malloc_stats();
printf("\nNow freeing 100k\n");
free(p1);
malloc_stats();
pad = MAX_SIZET;
printf("\nNow calling malloc_trim, pad=%p\n", pad);
malloc_trim(pad);
malloc_stats();
}
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list