smaps 內(nèi)存分布

hhuccpj

大蝦們，晚上好~

我在分析一個(gè)程序內(nèi)存波動(dòng)的時(shí)候，抓取了/proc/pid/smaps數(shù)據(jù)
發(fā)現(xiàn)有一塊64M左右的內(nèi)存，其沒有權(quán)限，但又是private
像下面這個(gè)樣子
400df000-4048c000 ---p 00000000 00:00 0

請教下這段內(nèi)存是用來干什么的？
為什么屬于當(dāng)前進(jìn)程，當(dāng)前進(jìn)程又沒有權(quán)限去rw呢？

實(shí)在不明白，，，

Tinnal

這種段一般都是為了隔離其它的段，防止其它段越界訪問的。

gaojl0728

回復(fù) 1# hhuccpj


    64M? 是linux 64 bit？ 那是glibc 給內(nèi)存池分配的， 64位linux glibc 會(huì)給每個(gè)線程分配一個(gè)arena, 每個(gè)arena至少有1個(gè)64M的heap， 應(yīng)該就是這個(gè)heap.

hhuccpj

今天我發(fā)現(xiàn)這塊會(huì)慢慢被修改為re-p，應(yīng)該不是保護(hù)

hhuccpj

今天我發(fā)現(xiàn)這塊內(nèi)存會(huì)滿滿被修改為rw-p�？雌饋硐袷窍萴map，flag設(shè)置為空了，再然后慢慢mprotect修改。上午分析我也在想應(yīng)該是內(nèi)存池。我是64位的機(jī)子。但我內(nèi)存明明是夠的，為什么會(huì)觸發(fā)再來一塊呢？思考中，，，

gaojl0728

回復(fù) 5# hhuccpj


    小伙很有前途啊， 觀察問題很仔細(xì)， 從glibc代碼來看， 的確是一開始映射的flags為0， 后來通過mprotect改成rw的
你如果用strace跟蹤應(yīng)該能抓到這個(gè)過程。

上代碼:
static heap_info *
internal_function
#if __STD_C
new_heap(size_t size, size_t top_pad)
#else
new_heap(size, top_pad) size_t size, top_pad;
#endif
{
  size_t page_mask = malloc_getpagesize - 1;
  char *p1, *p2;
  unsigned long ul;
  heap_info *h;

  if(size+top_pad < HEAP_MIN_SIZE)
    size = HEAP_MIN_SIZE;
  else if(size+top_pad <= HEAP_MAX_SIZE)
    size += top_pad;
  else if(size > HEAP_MAX_SIZE)
    return 0;
  else
    size = HEAP_MAX_SIZE;
  size = (size + page_mask) & ~page_mask;

  /* A memory region aligned to a multiple of HEAP_MAX_SIZE is needed.
     No swap space needs to be reserved for the following large
     mapping (on Linux, this is the case for all non-writable mappings
     anyway). */
  p2 = MAP_FAILED;
  if(aligned_heap_area) {
    p2 = (char *)MMAP(aligned_heap_area, HEAP_MAX_SIZE, PROT_NONE,
                      MAP_PRIVATE|MAP_NORESERVE);
    aligned_heap_area = NULL;
    if (p2 != MAP_FAILED && ((unsigned long)p2 & (HEAP_MAX_SIZE-1))) {
      munmap(p2, HEAP_MAX_SIZE);
      p2 = MAP_FAILED;
    }
  }
  if(p2 == MAP_FAILED) {
    p1 = (char *)MMAP(0, HEAP_MAX_SIZE<<1, PROT_NONE,
                      MAP_PRIVATE|MAP_NORESERVE);
    if(p1 != MAP_FAILED) {
      p2 = (char *)(((unsigned long)p1 + (HEAP_MAX_SIZE-1))
                    & ~(HEAP_MAX_SIZE-1));
      ul = p2 - p1;
      if (ul)
        munmap(p1, ul);
      else
        aligned_heap_area = p2 + HEAP_MAX_SIZE;
      munmap(p2 + HEAP_MAX_SIZE, HEAP_MAX_SIZE - ul);
    } else {
      /* Try to take the chance that an allocation of only HEAP_MAX_SIZE
         is already aligned. */
      p2 = (char *)MMAP(0, HEAP_MAX_SIZE, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE);
      if(p2 == MAP_FAILED)
        return 0;
      if((unsigned long)p2 & (HEAP_MAX_SIZE-1)) {
        munmap(p2, HEAP_MAX_SIZE);
        return 0;
      }
    }
  }
  if(mprotect(p2, size, PROT_READ|PROT_WRITE) != 0) {
    munmap(p2, HEAP_MAX_SIZE);
    return 0;
  }
  h = (heap_info *)p2;
  h->size = size;
  h->mprotect_size = size;
  THREAD_STAT(stat_n_heaps++);
  return h;
}

hhuccpj

哈哈，謝謝夸獎(jiǎng)，我怎么感覺有點(diǎn)飄的感覺，開個(gè)玩笑。我是想strace抓一下的，但這個(gè)問題只在高caps長時(shí)間下才發(fā)生，strace上去后性能上不去。我懷疑我用的下層平臺(tái)有人改東西了，如大家所述的話，應(yīng)該有動(dòng)態(tài)加減線程數(shù)

gaojl0728

回復(fù) 7# hhuccpj


有兩種情況glibc會(huì)創(chuàng)建新的64M heap,
一種是新建線程如果在堆上分配內(nèi)存會(huì)觸發(fā)glibc分配, 另一種是老線程前面的64M heap用光了也會(huì)新分配新的，多個(gè)heap會(huì)穿成一個(gè)鏈表。

hhuccpj

嗯，，我生日0729，比你晚一天，大哥在上，請受小弟一拜

gaojl0728

回復(fù) 9# hhuccpj


    你哪年的，還不知道誰大呢。我84