The following snippet (thanks zilch) illustrates a cool
undiscovered-as-of-yet crash in ORBit-Python with both ORBit-0.5.8 and
0.5.12:
import CORBA
for o in range(0,4):
orb = CORBA.ORB_init()
del(orb)
As always I am finding these neat new ways to crash o-p. This time, what
happens was discussed on #gnome:
<kiko> hmmm I think I know what it is.
<kiko> this crash happens when I have multiple orb = ORB_init() + del(orb)
calls
<kiko> which means I am releasing the orb, recreating it, and releasing it
again. does that work?
<markmc> kiko, I think in ORBit, ORBit_init didn't do a
CORBA_Object_duplicate on the existing ORB before returning it, so you
would only be allowed to release it once
<kiko> hmmm. i'll have to work around this to avoid a crash in the
testsuite.
<markmc> kiko, I remember Michael talking about this recently....
<markmc> kiko, its different in ORBit2
<kiko> markmc: I see. I'll put this on the ML to see what Tack says.
<markmc> kiko, but we didn't want to introduce leaks into old ORBit progs
by changing the behaviour
<kiko> Hmmmm. I understand.
So I think we're not allowed to create the orb multiple times. To work
around this, there are a couple of solutions I see:
a) Make the ORB a special object, so it's release is just a dummy release
and it only gets cleaned up by Python on exit (no big deal IMHO but this
isn't really fixing it).
b) Make PyObject release check if it's an orb and if so, don't release it.
We would have to change ORB_init() to not really create two orbs if we
didn't want to leak, of course. Well, Tack, opinion? I haven't looked at
the ORBit code, but I'll do so now.
Oh, I also fixed PACKAGE=orbiit-python in configure.in and configure that
SOMEBODY checked into the tree this week.
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL
|
