Normally you see a bad_alloc when a program tries to allocate memory and it can't (because there isn't enough in the system). Could you run the simulator in the debugger and see where it's actually coming from?
Ali On 04.06.2013 08:06, Maxime Chéramy wrote: > Hi, > > I've just updated my instance of gem5 with the last changes from the mercurial repo. The code still compile properly but when I try to run a bench in SE mode, it crashes quickly: > > command line: build/X86/gem5.opt configs/example/se.py -n 1 --cpu-type=timing --caches --l2cache --l1d_size=256B --l1d_assoc=4 --l1i_size=256B --l1i_assoc=4 --l2_size=16kB --l2_assoc=4 --num-l2caches=1 -c /home/max/bench/automotive/basicmath/basicmath_small > Global frequency set at 1000000000000 ticks per second > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Program aborted at cycle 0 > > My last update was the 28th of February and the exact same command line was working (I still have a copy of the directory before the update). > > Do you have any opinion or suggestion? I have not tried yet "scons -c", I am rebuilding currently. > > Regards, > > Maxime. > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] Links: ------ [1] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users