qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1.3 1/5] qom: fix refcount of non-heap-allocated


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1.3 1/5] qom: fix refcount of non-heap-allocated objects
Date: Mon, 26 Nov 2012 17:08:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Il 26/11/2012 16:49, Anthony Liguori ha scritto:
> But object_property_add_child() will take a reference.
> When the parent object goes away, this will cause that reference to get
> dropped and ultimately the child object to be destroyed.

This is still wrong if you have:

  object_init(&obj->subobj, ...)
  foo(&obj->subobj);
  object_property_add_child()

where foo() does a ref+unref pair (see the pattern of scsi_req_enqueue
for example, even though it's not QOM).

The object's memory area is being kept live by the parent, so it
logically has a nonzero reference count.

We don't have any example of embedding yet in the tree, except for
buses, so I think we are somewhat free to set the rules.

As I said elsewhere in the thread, the rule I'd prefer the most is "it
doesn't matter whether an object is statically- or
dynamically-allocated".  That is, even for an embedded object which you
create in instance_init, you should object_unref it explicitly, either
in instance_finalize or after initializing it (as you prefer).

Note that instance_finalize will anyway have an object_unparent of the
embedded object, in order to remove any cyclical references, so it's not
a big change.

> IOW, this change causes embedded objects to get leaked AFAICT.

Hmm, patch 4 in the series offsets this by doing

 void qbus_free(BusState *bus)
 {
-    if (bus->qom_allocated) {
-        object_delete(OBJECT(bus));
-    } else {
-        object_finalize(OBJECT(bus));
-        if (bus->glib_allocated) {
-            g_free(bus);
-        }
-    }
+    object_delete(OBJECT(bus));
 }

So at the end of the series there is no leak.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]