How to track down a double free or corruption error

Question

When I run my  C    program it crashes with this error        glibc detected     load  double free or corruption   prev     0x0000000000c6ed50       How can I track down the error   I tried using print  std  cout  statements  without success  Could gdb make this easier

User · Answer

You can use valgrind to debug it    include lt stdio h gt   include lt stdlib h gt   int main      char  x   malloc 100    free x    free x    return 0      sand PS-CNTOS-64-S11 testbox   vim t1 c  sand PS-CNTOS-64-S11 testbox   cc -g t1 c -o t1  sand PS-CNTOS-64-S11 testbox     t1     glibc detected       t1  double free or corruption  top   0x00000000058f7010             Backtrace             lib64 libc so 6 0x3a3127245f   lib64 libc so 6 cfree 0x4b  0x3a312728bb    t1 0x400500   lib64 libc so 6   libc start main 0xf4  0x3a3121d994    t1 0x400429          Memory map           00400000-00401000 r-xp 00000000 68 02 30246184                            home sand testbox t1 00600000-00601000 rw-p 00000000 68 02 30246184                            home sand testbox t1 058f7000-05918000 rw-p 058f7000 00 00 0                                   heap  3a30e00000-3a30e1c000 r-xp 00000000 68 03 5308733                         lib64 ld-2 5 so 3a3101b000-3a3101c000 r--p 0001b000 68 03 5308733                         lib64 ld-2 5 so 3a3101c000-3a3101d000 rw-p 0001c000 68 03 5308733                         lib64 ld-2 5 so 3a31200000-3a3134e000 r-xp 00000000 68 03 5310248                         lib64 libc-2 5 so 3a3134e000-3a3154e000 ---p 0014e000 68 03 5310248                         lib64 libc-2 5 so 3a3154e000-3a31552000 r--p 0014e000 68 03 5310248                         lib64 libc-2 5 so 3a31552000-3a31553000 rw-p 00152000 68 03 5310248                         lib64 libc-2 5 so 3a31553000-3a31558000 rw-p 3a31553000 00 00 0 3a41c00000-3a41c0d000 r-xp 00000000 68 03 5310264                         lib64 libgcc s-4 1 2-20080825 so 1 3a41c0d000-3a41e0d000 ---p 0000d000 68 03 5310264                         lib64 libgcc s-4 1 2-20080825 so 1 3a41e0d000-3a41e0e000 rw-p 0000d000 68 03 5310264                         lib64 libgcc s-4 1 2-20080825 so 1 2b1912300000-2b1912302000 rw-p 2b1912300000 00 00 0 2b191231c000-2b191231d000 rw-p 2b191231c000 00 00 0 7ffffe214000-7ffffe229000 rw-p 7ffffffe9000 00 00 0                       stack  7ffffe2b0000-7ffffe2b4000 r-xp 7ffffe2b0000 00 00 0                       vdso  ffffffffff600000-ffffffffffe00000 ---p 00000000 00 00 0                   vsyscall  Aborted  sand PS-CNTOS-64-S11 testbox      sand PS-CNTOS-64-S11 testbox   vim t1 c  sand PS-CNTOS-64-S11 testbox   cc -g t1 c -o t1  sand PS-CNTOS-64-S11 testbox   valgrind --tool memcheck   t1   20859   Memcheck  a memory error detector   20859   Copyright  C  2002-2009  and GNU GPL d  by Julian Seward et al    20859   Using Valgrind-3 5 0 and LibVEX  rerun with -h for copyright info   20859   Command    t1   20859     20859   Invalid free     delete   delete     20859      at 0x4A05A31  free  vg replace malloc c 325    20859      by 0x4004FF  main  t1 c 8    20859    Address 0x4c26040 is 0 bytes inside a block of size 100 free d   20859      at 0x4A05A31  free  vg replace malloc c 325    20859      by 0x4004F6  main  t1 c 7    20859     20859     20859   HEAP SUMMARY    20859       in use at exit  0 bytes in 0 blocks   20859     total heap usage  1 allocs  2 frees  100 bytes allocated   20859     20859   All heap blocks were freed -- no leaks are possible   20859     20859   For counts of detected and suppressed errors  rerun with  -v   20859   ERROR SUMMARY  1 errors from 1 contexts  suppressed  4 from 4   sand PS-CNTOS-64-S11 testbox      sand PS-CNTOS-64-S11 testbox   valgrind --tool memcheck --leak-check full   t1   20899   Memcheck  a memory error detector   20899   Copyright  C  2002-2009  and GNU GPL d  by Julian Seward et al    20899   Using Valgrind-3 5 0 and LibVEX  rerun with -h for copyright info   20899   Command    t1   20899     20899   Invalid free     delete   delete     20899      at 0x4A05A31  free  vg replace malloc c 325    20899      by 0x4004FF  main  t1 c 8    20899    Address 0x4c26040 is 0 bytes inside a block of size 100 free d   20899      at 0x4A05A31  free  vg replace malloc c 325    20899      by 0x4004F6  main  t1 c 7    20899     20899     20899   HEAP SUMMARY    20899       in use at exit  0 bytes in 0 blocks   20899     total heap usage  1 allocs  2 frees  100 bytes allocated   20899     20899   All heap blocks were freed -- no leaks are possible   20899     20899   For counts of detected and suppressed errors  rerun with  -v   20899   ERROR SUMMARY  1 errors from 1 contexts  suppressed  4 from 4   sand PS-CNTOS-64-S11 testbox     One possible fix    include lt stdio h gt   include lt stdlib h gt   int main      char  x   malloc 100    free x    x NULL   free x    return 0      sand PS-CNTOS-64-S11 testbox   vim t1 c  sand PS-CNTOS-64-S11 testbox   cc -g t1 c -o t1  sand PS-CNTOS-64-S11 testbox     t1  sand PS-CNTOS-64-S11 testbox     sand PS-CNTOS-64-S11 testbox   valgrind --tool memcheck --leak-check full   t1   20958   Memcheck  a memory error detector   20958   Copyright  C  2002-2009  and GNU GPL d  by Julian Seward et al    20958   Using Valgrind-3 5 0 and LibVEX  rerun with -h for copyright info   20958   Command    t1   20958     20958     20958   HEAP SUMMARY    20958       in use at exit  0 bytes in 0 blocks   20958     total heap usage  1 allocs  1 frees  100 bytes allocated   20958     20958   All heap blocks were freed -- no leaks are possible   20958     20958   For counts of detected and suppressed errors  rerun with  -v   20958   ERROR SUMMARY  0 errors from 0 contexts  suppressed  4 from 4   sand PS-CNTOS-64-S11 testbox     Check out the blog on using Valgrind Link

User · Answer

I know this is a very old thread  but it is the top google search for this error  and none of the responses mention a common cause of the error   Which is closing a file you ve already closed   If you re not paying attention and have two different functions close the same file  then the second one will generate this error

User · Answer

You can use gdb  but I would first try Valgrind   See the quick start guide   Briefly  Valgrind instruments your program so it can detect several kinds of errors in using dynamically allocated memory  such as double frees and writes past the end of allocated blocks of memory  which can corrupt the heap   It detects and reports the errors  as soon as they occur  thus pointing you directly to the cause of the problem

User · Answer

Are you using smart pointers such as Boost shared ptr  If so  check if you are directly using the raw pointer anywhere by calling get    I ve found this to be quite a common problem   For example  imagine a scenario where a raw pointer is passed  maybe as a callback handler  say  to your code  You might decide to assign this to a smart pointer in order to cope with reference counting etc  Big mistake  your code doesn t own this pointer unless you take a deep copy  When your code is done with the smart pointer it will destroy it and attempt to destroy the memory it points to since it thinks that no-one else needs it  but the calling code will then try to delete it and you ll get a double free problem   Of course  that might not be your problem here  At it s simplest here s an example which shows how it can happen  The first delete is fine but the compiler senses that it s already deleted that memory and causes a problem  That s why assigning 0 to a pointer immediately after deletion is a good idea   int main int argc  char  argv          char  ptr   new char 20        delete   ptr      ptr   0      Comment me out and watch me crash and burn      delete   ptr      Edit  changed delete to delete    as ptr is an array of char

User · Answer

If you re using glibc  you can set the MALLOC CHECK  environment variable to 2  this will cause glibc to use an error tolerant version of malloc  which will cause your program to abort at the point where the double free is done   You can set this from gdb by using the set environment MALLOC CHECK  2 command before running your program  the program should abort  with the free   call visible in the backtrace   see the man page for malloc   for more information

User · Answer

With modern C   compilers you can use sanitizers to track   Sample example     My program    cat d free cxx   include lt iostream gt   using namespace std   int main         int   i   new int       delete i       i   NULL     delete i      Compile with address sanitizers      g  -7 1 d free cxx -Wall -Werror -fsanitize address -g   Execute         a out                                                                      4836  ERROR  AddressSanitizer  attempting double-free on 0x602000000010 in thread T0       0 0x7f35b2d7b3c8 in operator delete void   unsigned long   media sf shared gcc-7 1 0 libsanitizer asan asan new delete cc 140      1 0x400b2c in main  media sf shared jkr cpp d free d free cxx 11      2 0x7f35b2050c04 in   libc start main   lib64 libc so 6 0x21c04       3 0x400a08    media sf shared jkr cpp d free a out 0x400a08   0x602000000010 is located 0 bytes inside of 4-byte region  0x602000000010 0x602000000014  freed by thread T0 here       0 0x7f35b2d7b3c8 in operator delete void   unsigned long   media sf shared gcc-7 1 0 libsanitizer asan asan new delete cc 140      1 0x400b1b in main  media sf shared jkr cpp d free d free cxx 9      2 0x7f35b2050c04 in   libc start main   lib64 libc so 6 0x21c04   previously allocated by thread T0 here       0 0x7f35b2d7a040 in operator new unsigned long   media sf shared gcc-7 1 0 libsanitizer asan asan new delete cc 80      1 0x400ac9 in main  media sf shared jkr cpp d free d free cxx 8      2 0x7f35b2050c04 in   libc start main   lib64 libc so 6 0x21c04   SUMMARY  AddressSanitizer  double-free  media sf shared gcc-7 1 0 libsanitizer asan asan new delete cc 140 in operator delete void   unsigned long    4836  ABORTING   To learn more about sanitizers you can check this or this or any modern c   compilers  e g  gcc  clang etc   documentations

User · Answer

There are at least two possible situations    you are deleting the same entity twice you are deleting something that wasn t allocated   For the first one I strongly suggest NULL-ing all deleted pointers   You have three options    overload new and delete and track the allocations yes  use gdb -- then you ll get a backtrace from your crash  and that ll probably be very helpful as suggested -- use Valgrind -- it isn t easy to get into  but it will save you time thousandfold in the future

User · Answer

Three basic rules    Set pointer to NULL after free Check for NULL before freeing  Initialise pointer to NULL in the start    Combination of these three works quite well

[c++] How to track down a "double free or corruption" error

Examples related to c++

Examples related to c

Examples related to debugging

Examples related to free