I would echo Gabe sentiments. I've been suspicious of the trace-flags
causing memory corruption for awhile now, but every time I dig into it
there's some small error that I'm propagating through that finally surfaces.

In the big picture, I suspect that the trace-flags just exacerbate any kind
of memory-corruption issues since you are accessing things at such a
heavy-rate.

In terms of debugging, is there any code that you edited that is tagged when
you use "ExecEnable" rather than just "Exec"?

Also, if you can turn valgrind on for maybe the 1st thousand/million cycles
with ExecEnable you'll probably find something.

On Thu, Apr 2, 2009 at 7:28 PM, Gabriel Michael Black <gbl...@eecs.umich.edu
> wrote:

> 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 <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=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
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>



-- 
----------
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science & Engineering
University of Michigan
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to