On 10/4/2021 4:46 PM, Đức Anh via gem5-users wrote:
Dear all,

I am trying to use the checkpoint feature to skip the long and tired Linux booting part of the ARM FS simulation. However, Gem5 throws the Segmentation fault when I try to restore the checkpoint. It works fine with AtomicSimpleCPU, though.

Here is the script I used to take the checkpoint
- run ./m5 checkpoint through the connected terminal
- in the python script, run m5.checkpoint("m5out/cpt.%d") and m5.simulate() 
again.

Then I restore the checkpoint by:
m5.instantiate(<checkpoint_dir>)
m5.simulate()

There is no CPU switching. I used DeriveO3CPU

I also tried the fs.py script with --checkpoint-restore option but the problem persists. Here is the error log:

--- BEGIN LIBC BACKTRACE ---
build/ARM/gem5.opt(_ZN4gem515print_backtraceEv+0x2c)[0x55a2b680abec]
build/ARM/gem5.opt(+0x1c346ef)[0x55a2b68266ef]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fa8ee493980]
--- END LIBC BACKTRACE ---
Segmentation fault (core dumped)

I read in one of the older emails that fs.py is outdated. Perhaps dealing with checkpoint and DerivO3CPU need another way?

See recent posts - folks are on the trail of a bug in either
the C++ code, C/C++ libraries, or C++ compiler / tool chain.
If it's the same bug then it has to do with the simulator's
memory management somehow (or a pointer gets zapped) - the
result is a bad free.  This may NOT be the same issue.  The
backtrace I get from gem5.opt indicates a bad free with
tcmalloc reporting it.

fs.py has worked for me, maybe with some customizations.
I think that the wording about it is trying to suggest that
it's perhaps a bit rigid or limiting for things a lot of people
may want to do ...

Regards - Eliot Moss
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to