7e303da76f
The DictImporter's __del__ method calls unload, and that imports sys.modules so that it can remove the modules that the DictImporter had set up as the importer goes away. Unfortunately, the importer only goes away when python is shutting down, and at that time some aspects of the system, namely sys.meta_path, have been cleaned up. When unload tries to import sys, that causes an exception which scons/python reports but which doesn't do anything bad otherwise. In all of the examples of this older style of import object online, none had a __del__ method, and none worried about cleaning up sys.modules when they went away. In light of that, I've removed the __del__ method entirely. Another reason I think it's safe to remove __del__ is that the importer was not actually being deleted even when it was removed from sys.meta_path, and all the modules it had loaded where removed from sys.modules. I think that was because the SimObject classes that it had set up still had references (they are used later in the SConscript), and those would, either directly or indirectly, refer back to the modules and the importer. Those remaining references kept the importer alive, preventing __del__ from being called before all those other objects were cleaned up. I think in python 2, the order things were cleaned up just so happened to avoid trying to import sys when it was no longer possible, but in python 3 that changed and resulted in this exception being thrown. I've tried building gem5 with scons running under python 2 and python 3, and with this change there is no error at shutdown. Both also produce a gem5 binary which can run hello world without problems. Change-Id: Ib1f5c7403df57fc420cec7ec0fef20a164a06991 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27247 Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/documentation/general_docs/building for more details and options. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.