Another approach, if you know the tick where the assertion failure happens, is to skip compression but limit the trace size by using the --trace-start flag to only start tracing some number of ticks before the assert. You have to just guess at a good number of ticks to back up to balance trace size vs. capturing the info you need, but in general I end up capturing 10X more trace than I need anyway for debugging. It also saves a lot of time, since generating the trace slows the simulation way down, and you don't bother doing that for the first part of the simulation.
Steve On Wed, Apr 11, 2012 at 10:51 AM, Ali Saidi <[email protected]> wrote: > ** > > The only think that you could do is install a SIGABRT handler that would > close all the open files gracefully. I believe abort() closes all open > files, but there might be unencoded output in the gzstream object that > hasn't been flushed. > > > > Ali > > On 11.04.2012 13:19, Andrew Cebulski wrote: > > Hi all, > > When running a trace to debug a problem that triggers an assertion, > I've tried outputting a compressed format. Unfortunately, it seems that > the file is closed improperly, resulting in a corrupt trace. This can be > seen easily by trying to zcat the tail of the file. It seems like their > should be a hook to let the compressed file close correctly before exiting > gem5 after an assertion is triggered. Is anyone familiar with where and > how this is currently done in the source code? > > Thanks, > Andrew > > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
