#16 Object reference creation leaks memory

closed-fixed
None
5
2001-05-27
2001-05-27
No

In the old days, when O-P was young, we used to have
one Python instance for each CORBA Object reference.
This is no longer true, as Tack explains:

<Tack> With _narrow(), you can have a single CORBA
object represented by two different python objects.

This means we now will create a new reference on each
servant_to_reference() call. This also means, however,
that a lacking __del__ function will leak memory like
mad

Discussion

  • Christian Reis

    Christian Reis - 2001-05-27

    Logged In: YES
    user_id=222305

    I've attached the first version of my patch. This patch is
    _incorrect_ as Tack states because it moves us back to the
    'single Object reference epoch'.

     
  • Christian Reis

    Christian Reis - 2001-05-27

    Patch #1 for leak

     
  • Christian Reis

    Christian Reis - 2001-05-27
    • assigned_to: nobody --> kiko_async
     
  • Christian Reis

    Christian Reis - 2001-05-27

    Patch #2 for leak

     
  • Christian Reis

    Christian Reis - 2001-05-27

    Logged In: YES
    user_id=222305

    The second patch attached doesn't implement single object
    references; Tack says it's the proper fix. However, there is
    one caveat: software that relies on A._this() == A._this()
    breaks.

    This is trickier than it seems: If your software holds a
    reference to A and another reference to A is created, you
    can't == them. Tack says it's an issue:

    <Tack> Compromise 1: use a single, unique reference mapped
    to a (CORBA Object, IDL interface) tuple.
    Tack Tack_
    <Tack> Compromise 2: implement __equal__ (or whatever it is)
    to handle this case in objrefs.

     
  • Jason Tackaberry

    Logged In: YES
    user_id=19625

    The lack of class destructor is a symptom of my incomplete
    objref changes. It'll get addressed soon.

    Strictly speaking, CORBA references to the same object
    aren't required to be the same. That's why _is_equivalent
    exists.

    The resolution, as I see it, is to implement compromise 1,
    since compromise 2 is fundamentally broken for reasons
    Roland pointed out (ref1 == ref2 but dict[ref1] !=
    dict[ref2]). Code that takes advantage of ref1 == ref2
    would be O-P specific mind you, so that will need to be
    documented.

     
  • Jason Tackaberry

    • assigned_to: kiko_async --> tack
     
  • Jason Tackaberry

    • status: open --> closed
     
  • Jason Tackaberry

    Logged In: YES
    user_id=19625

    Committed patch #2. No more leaks for objref creation.
    Thanks kiko.

     
  • Christian Reis

    Christian Reis - 2001-05-27
    • status: closed --> closed-fixed
     
  • Christian Reis

    Christian Reis - 2001-05-27

    Logged In: YES
    user_id=222305

    Tack means commited to his local tree. This bug is now
    closed and this patch has evolved into v3, which is attached
    to bug 427771

     

Log in to post a comment.