title: Understanding "corrupted size vs. prev_size" glibc error
body: <p>I have implemented a JNA bridge to FDK-AAC. Source code can be found in <a href="https://github.com/sheinbergon/jna-aac-encoder" rel="noreferrer">here</a></p>
  
  <p>When bench-marking my code, I can get hundreds of successful runs on the same input, and then occasionally a C-level crash that'll kill the entire process, causing a core-dump to be generated:</p>
  
  <p>Looking at the core dump, it looks like this:</p>
  
  <pre><code>#1  0x00007f3e92e00f5d in __GI_abort () at abort.c:90
  #2  0x00007f3e92e4928d in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f3e92f70528 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:181
  #3  0x00007f3e92e5064a in malloc_printerr (action=&lt;optimized out&gt;, str=0x7f3e92f6cdee "corrupted size vs. prev_size", ptr=&lt;optimized out&gt;, ar_ptr=&lt;optimized out&gt;) at malloc.c:5426
  #4  0x00007f3e92e5304a in _int_free (av=0x7f3de0000020, p=&lt;optimized out&gt;, have_lock=0) at malloc.c:4337
  #5  0x00007f3e92e5744e in __GI___libc_free (mem=&lt;optimized out&gt;) at malloc.c:3145
  #6  0x00007f3e113921e9 in FDKfree (ptr=0x7f3de009df60) at libSYS/src/genericStds.cpp:233
  #7  0x00007f3e1130d7d3 in Free_AacEncoder (p=0x7f3de0115740) at libAACenc/src/aacenc_lib.cpp:407
  #8  0x00007f3e1130fbb3 in aacEncClose (phAacEncoder=0x7f3de0115740) at libAACenc/src/aacenc_lib.cpp:1395
  </code></pre>
  
  <p>This back/stack trace error is reproducible if I run repeat benchmark enough times , though I'm having a hard time understanding what might be the cause for such error? Memory allocated to pointer <code>0x7f3de009df60</code> is allocated inside the CPP/C code as well and I can guarantee the same instance that's allocated is being freed. The benchmark is, of course - single-threaded.</p>
  
  <p>After reading these:</p>
  
  <p><a href="https://heap-exploitation.dhavalkapil.com/diving_into_glibc_heap/security_checks.html" rel="noreferrer">security checks</a> &amp;&amp; 
  <a href="https://heap-exploitation.dhavalkapil.com/diving_into_glibc_heap/security_checks.html" rel="noreferrer">internal functions</a></p>
  
  <p>I'm still having a hard time understanding - what might be a real (non-exploitation, but rather error)) scenario that causes me to get the above error? and why does it happen very scarcely?</p>
  
  <p><strong>Current suspicion</strong>:</p>
  
  <p>Running a detailed backtrace, I get this input:</p>
  
  <pre><code>#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
          set = {__val = {4, 6378670679680, 645636045657660056, 90523359816, 139904561311072, 292199584, 139903730612120, 139903730611784, 139904561311088, 1460617926600, 47573685816, 4119199860131166208, 
              139904593745464, 139904553224483, 139904561311136, 288245657}}
          pid = &lt;optimized out&gt;
          tid = &lt;optimized out&gt;
  #1  0x00007f3e92e00f5d in __GI_abort () at abort.c:90
          save_stage = 2
          act = {__sigaction_handler = {sa_handler = 0x7f3de026db10, sa_sigaction = 0x7f3de026db10}, sa_mask = {__val = {139903730540556, 19, 30064771092, 812522497172832284, 139903728706672, 1887866374039011357, 
                139900298780168, 3775732748407067896, 763430436865, 35180077121538, 4119199860131166208, 139904561311552, 139904553065676, 1, 139904561311584, 139904561312192}}, sa_flags = 4096, 
            sa_restorer = 0x14}
          sigs = {__val = {32, 0 &lt;repeats 15 times&gt;}}
  #2  0x00007f3e92e4928d in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f3e92f70528 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:181
          ap = {{gp_offset = 40, fp_offset = 32574, overflow_arg_area = 0x7f3e11adf1d0, reg_save_area = 0x7f3e11adf160}}
          fd = &lt;optimized out&gt;
          list = &lt;optimized out&gt;
          nlist = &lt;optimized out&gt;
          cp = &lt;optimized out&gt;
          written = &lt;optimized out&gt;
  #3  0x00007f3e92e5064a in malloc_printerr (action=&lt;optimized out&gt;, str=0x7f3e92f6cdee "corrupted size vs. prev_size", ptr=&lt;optimized out&gt;, ar_ptr=&lt;optimized out&gt;) at malloc.c:5426
          buf = "00007f3de009e9f0"
          cp = &lt;optimized out&gt;
          ar_ptr = &lt;optimized out&gt;
          ptr = &lt;optimized out&gt;
          str = 0x7f3e92f6cdee "corrupted size vs. prev_size"
          action = &lt;optimized out&gt;
  #4  0x00007f3e92e5304a in _int_free (av=0x7f3de0000020, p=&lt;optimized out&gt;, have_lock=0) at malloc.c:4337
          size = 2720
          fb = &lt;optimized out&gt;
          nextchunk = 0x7f3de009e9f0
          nextsize = 736
          nextinuse = &lt;optimized out&gt;
          prevsize = &lt;optimized out&gt;
          bck = &lt;optimized out&gt;
          fwd = &lt;optimized out&gt;
          errstr = 0x0
          locked = &lt;optimized out&gt;
  #5  0x00007f3e92e5744e in __GI___libc_free (mem=&lt;optimized out&gt;) at malloc.c:3145
          ar_ptr = &lt;optimized out&gt;
          p = &lt;optimized out&gt;
          hook = &lt;optimized out&gt;
  #6  0x00007f3e113921e9 in FDKfree (ptr=0x7f3de009df60) at libSYS/src/genericStds.cpp:233
  No locals.
  #7  0x00007f3e1130d7d3 in Free_AacEncoder (p=0x7f3de0115740) at libAACenc/src/aacenc_lib.cpp:407
  No locals.
  #8  0x00007f3e1130fbb3 in aacEncClose (phAacEncoder=0x7f3de0115740) at libAACenc/src/aacenc_lib.cpp:1395
          hAacEncoder = 0x7f3de009df60
          err = AACENC_OK
  </code></pre>
  
  <ul>
  <li>In frame <strong>#6</strong>, you can see the pointer in questions is  <code>0x7f3de009df60</code>.</li>
  <li>In frame <strong>#4</strong>, you can see that the size is 2720, which is indeed the expected size of the structure being released.</li>
  <li>However the address of <code>nextchunk</code> is <code>0x7f3de009e9f0</code>, which is only 2704 bytes after the current pointer which is being released.</li>
  <li>I can confirm this is always the case when the error reproduces.</li>
  <li><strong>Could this be a strong indication of the error I'm facing ??</strong></li>
  </ul>