Does this happen when you start tracing sooner? I'd suggest valgrind,
especially if you can make the segfault happen quickly. If you wait
for your simulation to get to 14000 ticks in valgrind, you may
die before you see the result. There's a suppression file in util
which should cut down on the noise.
Gabe
Quoting Geoffrey Blake bla...@umich.edu:
I stumbled upon what appears to be a memory corruption bug in the current M5
repository. If on the command line I enter:
% ./build/ALPHA_FS/m5.opt -trace-flags=ExecEnable
-trace-start=14000 fs.py -b benchmark -t -n cpus more
parameters. The simulator will error with a segmentation fault or
occasionally an assert not long after starting to trace instructions.
I have run this through gdb in with m5.debug and see the same errors, the
problem is the stack trace showing the cause of the seg fault or assert
changes depending on the inputs to the simulator. So, I have not been able
to pin point this bug which appears to be a subtle memory corruption
somewhere in the code. This error does not happen for other trace flags such
as the Cache trace flag. It appears linked solely to the instruction
tracing mechanism. Has anybody else seen this bug?
I'm using an up to date repository I pulled from m5sim.org this morning.
Thanks,
Geoff
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
