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 1400000000000 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 <[email protected]>: > 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=1400000000000 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 [email protected] http://m5sim.org/mailman/listinfo/m5-dev
