casseopea2 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

sbrk fails when devmem and mmap are disabled (FreeBSD 71-PRERELEASE, 32-bit) #93

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. compile the program:
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

main() {
  void *m1 = malloc(100*1024*1024); printf("allocated m1=%p\n", m1);
  void *m2 = malloc(100*1024*1024); printf("allocated m2=%p\n", m2);
  void *m3 = malloc(100*1024*1024); printf("allocated m3=%p\n", m3);
  void *m4 = malloc(100*1024*1024); printf("allocated m4=%p\n", m4);
  void *m5 = malloc(100*1024*1024); printf("allocated m5=%p\n", m5);
  void *m6 = malloc(100*1024*1024); printf("allocated m6=%p\n", m6);
  printf("alloc: %p %p %p %p %p %p\n", m1, m2, m3, m4, m5, m6); sleep(5);
  free(m6); printf("freed m6\n"); sleep(5);
  free(m5); printf("freed m5\n"); sleep(5);
  free(m4); printf("freed m4\n"); sleep(5);
  free(m3); printf("freed m3\n"); sleep(5);
  free(m2); printf("freed m2\n"); sleep(5);
  free(m1); printf("freed m1\n"); sleep(5);
}

2. Run it: TCMALLOC_SKIP_MMAP=1 TCMALLOC_DEVMEM_START=0
LD_PRELOAD=/usr/local/lib/libtcmalloc.so ./test

3. See that output has zero as m6:
alloc: 0x81ca000 0xe5ca000 0x14daa000 0x1b1aa000 0x215aa000 0x0

What is the expected output? What do you see instead?
expected all allocations to succeed

What version of the product are you using? On what operating system?
1.0-rc2

Please provide any additional information below.
Allocation succeeds when TCMALLOC_SKIP_MMAP=0, it just falls back to mmap
for m6.

So on 32-bit machine mmap is a fallback for sbrk not all the way around as
you suggested in your comment in PR#92. I added a comment in PR#92.

Original issue reported on code.google.com by visa_des...@yahoo.com on 7 Jan 2009 at 11:57

GoogleCodeExporter commented 9 years ago
Not sure that this is a bug report.  Indeed, we fall back onto mmap when sbrk 
fails
because it runs out of address space (which it sounds like is what is happening
here).  Indeed, that's why we fall back onto mmap when sbrk fails!

Sorry about the incorrect comment in PR#92; I was confused about the preference
between sbrk and mmap.

Original comment by csilv...@gmail.com on 8 Jan 2009 at 12:12