On 30 April 2018 at 01:18, Michael Clark <m...@sifive.com> wrote: > Quite a bit of our initialization code in several QOM classes allocate > memory that is not freed. e.g. the PLIC. Usually these functions are only > run once, but ideally all of the code should be memory clean. i.e. exit > without leaks. Many programs don't bother with this but I think it is a good > practice. > > Should we use dc->unrealize to point to an unrelalize function that calls > g_free? Is unrealize the QOM destructor?
unrealize is the destructor, yes, but we currently only use it for devices that are hot-pluggable (and thus unpluggable). For non-pluggable devices we currently generally don't worry about giving the objects a destructor, since it can never be called. This is a bit weird though, and I think there's a thread on-list somewhere where there's a proposal that we should (a) document better the best way to divide tasks between init/realize and (b) perhaps suggest that devices should init unrealize too. Board model code is also rather prone to "allocate and never free", because historically boards didn't have a QOM object to own the memory they allocated. This is why board code often does g_new0(MemoryRegion, 1) to allocate MemoryRegions, where device code would just have a MemoryRegion field in its device struct. Now that boards have real MachineState objects associated with them, it is possible to write them the way you write a device -- hw/arm/mps2.c has an example of this. Since again it doesn't have a destructor there's not much difference in practice, though: we still rely on the memory being freed on program exit. thanks -- PMM
