Error in long run cycles (double free or corruption )

[ahmed-shafik]

Dears,

I get the below error after running the DRAMSim2 on long run cycles (e.g. 140 cycle). Can ypu help me why I got this error ? I know that it is due freeing a pointer twice but how can I get this pointer ?

== Pending Transactions : 235 (140)==
//// Channel [0] ////
*** Error in `./DRAMSim': double free or corruption (fasttop): 0x00000000016e1ae0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x80a46)[0x7fe1e3035a46]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSsD1Ev+0x20)[0x7fe1e3955290]
./DRAMSim[0x41e14a]
./DRAMSim[0x41d09a]
./DRAMSim[0x41d506]
./DRAMSim[0x429a54]
./DRAMSim[0x429b58]
./DRAMSim[0x42d48b]
./DRAMSim[0x42d644]
./DRAMSim[0x4347e5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fe1e2fd6ea5]
./DRAMSim[0x403041]
======= Memory map: ========
00400000-0044d000 r-xp 00000000 fc:00 3955968 /home/ashafik/DRAMSIM/DRAMSim2/DRAMSim
0064d000-0064e000 r--p 0004d000 fc:00 3955968 /home/ashafik/DRAMSIM/DRAMSim2/DRAMSim
0064e000-0064f000 rw-p 0004e000 fc:00 3955968 /home/ashafik/DRAMSIM/DRAMSim2/DRAMSim
0064f000-00650000 rw-p 00000000 00:00 0
016a9000-016ed000 rw-p 00000000 00:00 0 [heap]
7fe1e2fb5000-7fe1e3174000 r-xp 00000000 fc:00 6033323 /lib/x86_64-linux-gnu/libc-2.17.so
7fe1e3174000-7fe1e3373000 ---p 001bf000 fc:00 6033323 /lib/x86_64-linux-gnu/libc-2.17.so
7fe1e3373000-7fe1e3377000 r--p 001be000 fc:00 6033323 /lib/x86_64-linux-gnu/libc-2.17.so
7fe1e3377000-7fe1e3379000 rw-p 001c2000 fc:00 6033323 /lib/x86_64-linux-gnu/libc-2.17.so
7fe1e3379000-7fe1e337e000 rw-p 00000000 00:00 0
7fe1e337e000-7fe1e3392000 r-xp 00000000 fc:00 6029530 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe1e3392000-7fe1e3592000 ---p 00014000 fc:00 6029530 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe1e3592000-7fe1e3593000 r--p 00014000 fc:00 6029530 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe1e3593000-7fe1e3594000 rw-p 00015000 fc:00 6029530 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe1e3594000-7fe1e3697000 r-xp 00000000 fc:00 6033269 /lib/x86_64-linux-gnu/libm-2.17.so
7fe1e3697000-7fe1e3897000 ---p 00103000 fc:00 6033269 /lib/x86_64-linux-gnu/libm-2.17.so
7fe1e3897000-7fe1e3898000 r--p 00103000 fc:00 6033269 /lib/x86_64-linux-gnu/libm-2.17.so
7fe1e3898000-7fe1e3899000 rw-p 00104000 fc:00 6033269 /lib/x86_64-linux-gnu/libm-2.17.so
7fe1e3899000-7fe1e397e000 r-xp 00000000 fc:00 1967052 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fe1e397e000-7fe1e3b7d000 ---p 000e5000 fc:00 1967052 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fe1e3b7d000-7fe1e3b85000 r--p 000e4000 fc:00 1967052 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fe1e3b85000-7fe1e3b87000 rw-p 000ec000 fc:00 1967052 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fe1e3b87000-7fe1e3b9c000 rw-p 00000000 00:00 0
7fe1e3b9c000-7fe1e3bbf000 r-xp 00000000 fc:00 6029422 /lib/x86_64-linux-gnu/ld-2.17.so
7fe1e3d98000-7fe1e3d9d000 rw-p 00000000 00:00 0
7fe1e3dba000-7fe1e3dbe000 rw-p 00000000 00:00 0
7fe1e3dbe000-7fe1e3dbf000 r--p 00022000 fc:00 6029422 /lib/x86_64-linux-gnu/ld-2.17.so
7fe1e3dbf000-7fe1e3dc1000 rw-p 00023000 fc:00 6029422 /lib/x86_64-linux-gnu/ld-2.17.so
7fff51963000-7fff51984000 rw-p 00000000 00:00 0 [stack]
7fff519e3000-7fff519e5000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)

[dramninjasUMD]

This is just a double free error (calling delete() on something that has already been deleted). I have tested DRAMSim2 extensively with valgrind, so it is unlikely that this error exists in the DRAMSim2 code. Have you made code changes?

[ahmed-shafik]

Is there any mention in the error log message to this deletion statement, however, the code run for the 1st 100 cycles fine ?

[dramninjasUMD]

This is the nature of memory corruption -- the program can run for a while before crashing. There's no mention in the log because the program itself is broken.

I'd recommend you just search for all the delete statements in the code, comment them out, and see how far you get. You'll have a huge memory leak, but that way you can at least confirm that it is a memory corruption issue.

After that, you'll probably have to learn how to use Valgrind if you want to find the actual source of the double free.