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

Reply via email to