On Wed, Jul 11, 2018 at 09:04:35PM +0200, Thomas Huth wrote: > On 11.07.2018 19:21, Paolo Bonzini wrote: > > On 10/07/2018 08:50, Peter Maydell wrote: > >>>> Yuck. The real problem here is that we're still requiring the > >>>> code that creates these QOM devices to manually set the parent > >>>> in the first place. It's not surprising that we don't get it right > >>>> (either parenting in the wrong place or not at all). I'd much > >>>> rather see us fix that properly than keep papering over places > >>>> where we get it wrong. > >>> Sorry, I'm still not an expert in all this QOM stuff yet ... so what do > >>> you exactly recommend to do instead? > >> I'm not clear either, but I don't think that what we're > >> currently doing can be right. > > > > Well, in theory it should work... I sent the expected flow in another > > email. > > Something that just came to my mind: > > bcm2836_init() creates the TYPE_BCM2835_PERIPHERALS object with > object_initialize(). This creates one reference to the object already. > Then the object is linked to its parent with > object_property_add_child(), which creates another reference to the > object. But where are the two references correctly destroyed again? One > is certainly destroyed by device_unparent later, but the initial one? > Could it be that we are simply lacking one object_unref() after the > object_property_add_child() here?
This seems to be true, but I'm confused about the reference counting model, here: What exactly guarantees there will be no other references to (e.g.) `&s->control` when `s` is freed? We know the references added by object_initialize(), object_property_add_child() and qdev_set_parent_bus() will be dropped, but what about other code calling object_ref()? -- Eduardo
