compiz team mailing list archive

[Daniel van Vugt <vanvugt@xxxxxxxxx>]

I've lost count of the leaks in unity I've looked at today (to fix bug
769957). My plan is to only fix what I need to to resolve that bug and
leave the others to this bug (or others).

The most common cause I've found is total misuse of the nux::Object
referencing model throughout the unity code. So often a floating
reference is created (one not marked as owned via SinkReference etc)
with refcount==1, and the author just calls UnReference which will
always fail in that situation. Because nux::Object::UnReference is
actually designed to fail in that situation (!)

I think the root cause really is the design of nux::Object. It is far
too confusing and dangerous for an object with refcount==1 to fail
UnReference. Programmers really don't expect that and it is not obvious
why initially (if you even bother to check the return value of
UnReference).

For now in bug 769957, I'm just working with the nux API as it is and
changing only unity to minimize potential side effects. But it feels
inelegant...

Would it ever be safe to make nux::Object::UnReference behave how people
expect it should?

-- 
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/758248

Title:
  memory leaking in compiz