junwang314 / eraser Goto Github PK

bt:

from /home/qiang/projects/eraser/mfree_spec.so
#1 0x00007fa95e0bf297 in e_queue_enque (p=0x71710d0, q=0xf32ae0) at util.h:73
#2 0x00007fa95e0bf82f in free (p=0x71710d0) at mfree.c:138
#3 0x0000000000455c05 in operator delete(void*) ()
#4 0x000000000046bb46 in cSimpleChannel::~cSimpleChannel() ()
#5 0x0000000000460357 in cObject::discard(cObject*) ()
#6 0x0000000000486e7e in cObject::~cObject() ()
#7 0x00000000004579dd in cHead::~cHead() ()
#8 0x000000000047f51f in cSimulation::~cSimulation() ()
#9 0x00007fa95d527901 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x00007fa95d527985 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x00007fa95d50d774 in __libc_start_main ()

from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00000000004027a9 in _start ()

Jun:

I found the gedit still works, but it just took TOO long. To speed up, you can first comment out the fprintf in e_queue_enque(). Then you run with gedit. After about 30s, the gedit window will pop up. And after another 30s, the gedit is fully loaded and ready to use.

This indicates that the current eraser setup will lead to very bad performance for gedit. The current setup is: one eraser thread per process and a fix-sized FIFO queue that can mostly hold 1024 buffers to be free'd.

Outputs of eraser to stdout will fail a SPEC run, because SPEC will compare the output of a benchmark program with the ground truth.