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/15089] malloc_trim always trims for large padding


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.


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