title: How to iterate all malloc chunks (glibc)
body: <p>I'm trying to iterate all the malloc_chunk in all arenas. (debugging based on core file, for memory leak and memory corruption investigation)</p>
  
  <p>As i know each arena have <em>top_chunk</em> which point to the top chunk inside of one arena, based on <em>top_chunk</em>, inside of it, there's <em>prev_size</em> and <em>size</em>, based on the code (glibc/malloc/malloc.c):
  <a href="https://i.stack.imgur.com/h02y7.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/h02y7.png" alt="enter image description here"></a> 
  I can get the previous continuous chunks, and then loop all the chunks in one arena. (i can statistic the chunks with the size and the number, which like WinDBG: !heap -stat -h) and also based on <em>prev_size</em> and <em>size</em>, i can check the chunk is corrupt or not.</p>
  
  <p>In arena(malloc_state), there's a member variable: <em>next</em> which point to next arena. Then i can loop all the arena's chunks.</p>
  
  <p>But i met a problem is if the chunk is not allocated, the prev_size is invalid, how to get the previous malloc_chunk?? Or this way is not correct.</p>
  
  <hr>
  
  <p>Question Background:</p>
  
  <p>The memory leak bug we have is memory leak reported in several online data node(our project is distributed storage cluster). </p>
  
  <p>What we did and result:</p>
  
  <ol>
  <li><p>We use valrgind to reproduce the bug in test cluster, but unfortunately we get nothing. </p></li>
  <li><p>I tried to investigate more about the heap, tried to analyze the heap chunk and follow the way which i did before in WinDBG(which have very interesting heap commands to digger the memory leak and memory corruption), but i was blocked by the Question which i asked.</p></li>
  <li><p>We use valgrind-massif to analyze the allocation(which i think it's very detail and interesting, could show which allocation takes how much memory). Massif show several clues, we follow this and check code, finally found the leak(a map is very huge, and in-proper usage of it, but i would erase in holder-class's destructor, that's why valgrind not report this).</p></li>
  </ol>
  
  <p>I'll digger more about the gdb-heap source code to know more about glic malloc structure.</p>