Hi all, I merged changeset 2367198921 which added support for dynamically creating Process objects during simulation. This feature is needed to allow applications to call the clone system call (which serves to fork a process) in the middle of simulation.
Inadvertently, this creates a problem with dynamically creating SimObjects which might be new to the simulator. The Process class uses a SimObject class as a base class. Both Process and SimObject use Params (normally set by Python) to initialize themselves. During clone, I duplicate the ProcessParams and pass them into the Process constructor while dynamically allocating an instance of a Process object. After I initialized ProcessParams and use them to create the new Process object, I deleted them (not wanting to leak memory). However, the SimObject class caches a const pointer to Params which can cause memory corruption after the free if the pointer is accessed. (Jason points this out with https://gem5-review.googlesource.com/c/public/gem5/+/18068.) The issue can be avoided by removing the cached Params pointer and instead only storing the relevant fields which are accessed by the class. However, SimObject establishes an accessor API for Params which other classes have also implemented. The derived classes essentially implement the same method with a cast to convert the Params to the derived class type. This leaves me in a bit of a bind since I am not sure what the established design principle is regarding Params. Conceptually, there is no reason why we could not store the relevant fields which each of the Params types provide in the respective classes. However, it is a fairly extensive change which could be contentious. Does anyone have a suggestion on how to go about resolving the issue? Regards, Brandon _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
