orbit-python-list

[Orbit-python-list] Leak in CORBA_ORB_object_to_string

[Christian R. R. <ki...@as...>]

Hi,

I've filed bug #55906 after uncovering what seems to be a leak in
object_to_string; I've triggered this through ORBit-Python's stress test
suite. I've had a look at the code, and apart from the codec (which seems
to be using codec_d's memory, so in principle it looks okay) everything
seems to be okay. Anyone have time to look into it?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Re: Stress test suite added.

[Jason T. <ta...@li...>]

> perform the requests and how much was leaked. The client-side leak reports
> are probably bogus at this point (since it reports leaking even though we
> all know orbit-python doesn't leak *grin*) but I'll work on it through the
> weekend if my visiting parents don't occupy me too much.

Well I went on that leak squashing binge last week and O-P doesn't leak
in most common cases, but for error conditions there might very well be
leaks.  So I'll look at that for sure, but not too closely until after
0.3.0 is released. 

> Jason, orbit-python as of now doesn't run the basic tests anymore! ORBPOA
> tests all fail when trying to run resolve_initial_references("RootPOA")

I see that!  Did you make any additional changes to the tests?  Because
two of the failures were attributed to ORBit bugs, and I can't see them
passing before.

The first is passing a bad value ("XXX") to resolve_initial_references.
It correctly fails, but then any subsequent call segfaults inside ORBit.

   http://bugzilla.gnome.org/show_bug.cgi?id=55726

The second causes string_to_object to incorrectly fail given a valid IOR
if it was previously invoked with an invalid IOR ("foo" say).

   http://bugzilla.gnome.org/show_bug.cgi?id=55729

I don't know how quickly these will get addressed.  The other bug I
reported didn't get acknowledged at all.

A few of the other tests in the test suite were rendered invalid by my
recent changes of moving implicit activation into servant_to_reference,
so you can call servant_to_reference in a non-active servant and it will
activate it if the POA supports implicit activation.

Anyway, I fixed the test suite up so it passes again. 

Jason.

[Orbit-python-list] Stress test suite added.

[Christian R. R. <ki...@as...>]

With minor testing and a heap of bugs and virtually no documentation, I
hereby commit the first incarnation of a stress test suite. (Jason's been
running a version with very little change). It reports client and
server-side leaks by monitoring /proc/#/status and prints out the time to
perform the requests and how much was leaked. The client-side leak reports
are probably bogus at this point (since it reports leaking even though we
all know orbit-python doesn't leak *grin*) but I'll work on it through the
weekend if my visiting parents don't occupy me too much.

Jason, orbit-python as of now doesn't run the basic tests anymore! ORBPOA
tests all fail when trying to run resolve_initial_references("RootPOA")
for some strange reason and I'm sure this has to do with your changes to
the ORB handling. Can you check on this? If not, I'll dig through the
changes myself to see what's going on.

Hope you all had a good week (trip was great; Rasmus Lerdorf was there, as
was Rik van Riel and Ken Coar) and trust you're all _not working on the
weekend_, except perhaps Roland.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Examples

[Jason T. <ta...@li...>]

If anyone has time to whip up some small examples demonstrating how to
use ORBit-Python, I'd like to include them for the 0.3.0 release.  Any
takers?

Jason.

[Orbit-python-list] Re: How should O-P handle references to deactivated objects

[Jason T. <ta...@li...>]

> And could we add a custom handler that we could attach at runtime to get
> the effect of manually loading objects in case they aren't there? This
> would be cool to workaround dynamic loading (though our objects would have
> to lose all state unless they persist).

CORBA has a provision for a POA to have a default servant, which handles
requests for unknown objects.  This could potentially be used for
something like this, but it's probably not the best solution.  ORBit
even supports this, but O-P doesn't yet.

> If we want stateful on-demand loading (think client holds reference to
> server; server dies, restarts; client uses reference) then the objects
> have to be persisted.

This stuff happens at a level below ORBit-Python.  If it can be done,
ORBit has to support it.

> The handler above could be placed in O-P. Is this a good idea, however?

Well, if OAF does it, and there are OAF bindings, I don't see any big
benefit.

Jason.

Re: [Orbit-python-list] Implications of latest commits (your test suite)

[Jason T. <ta...@li...>]

> And these are...? Are there any useful methods? (I guess the stuff in
> CORBA_Object.c)

That's right.  _is_equivalent, _hash, _narrow, _is_a, and so on ...

Jason.

Re: [Orbit-python-list] Implications of latest commits (your test suite)

[Christian R. R. <ki...@as...>]

On Mon, 28 May 2001, Jason Tackaberry wrote:

> You won't be able to do much really, except invoke the base CORBA.Object
> methods.  (Its __class__ would be CORBA.Object, and __dict__ would be
> empty.)

And these are...? Are there any useful methods? (I guess the stuff in
CORBA_Object.c)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Re: How should O-P handle references to deactivated objects

[Christian R. R. <ki...@as...>]

(Back!)

On Sun, 27 May 2001, Jason Tackaberry wrote:

> > Say we deactivate an object through poa.deactivate_object(). If references
> > were generated to that object, what happens when we try and dereference
> > them?
>
> The correct behaviour would be for the ORB to raise
> CORBA.OBJECT_NOT_EXIST.

And could we add a custom handler that we could attach at runtime to get
the effect of manually loading objects in case they aren't there? This
would be cool to workaround dynamic loading (though our objects would have
to lose all state unless they persist).

If we want stateful on-demand loading (think client holds reference to
server; server dies, restarts; client uses reference) then the objects
have to be persisted.

> I know that OAF handles on-demand server loading.  I don't think there's
> any provision for this in ORBit itself, but I could be wrong.

The handler above could be placed in O-P. Is this a good idea, however?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Bugzilla

[Jason T. <ta...@li...>]

I'm not very happy with SourceForge's bug tracking system, and since SF
seems to be having issues lately (anyone else getting connection
timeouts?) I went ahead and installed bugzilla.  I like its interface
better anyway.  Seems more to the point.

So from now on, report bugs to http://bugzilla.sault.org/ and let me
know if you encounter any problems with it.  (It's late, I'm tired, and
I whipped through the install.)

I'll leave the bugs section on SF open so I can move the current open
bugs over, which fortunately aren't many.

Jason.

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> Any news from the orbit-list about the bug being valid and fixable/in the
> process of fixing?

Nope.  Not even an acknowledgement.

I'll file the bug on bugzilla.

Jason.

Re: [Orbit-python-list] Latest commits

[Christian R. R. <ki...@as...>]

On Mon, 28 May 2001, Jason Tackaberry wrote:

> > Was the POA bug we identified fixed? You know, the one where deactivate
> > doesn't clear out some fields on the servant's _private structure?
>
> You mean the ORBit bug?  I added a work-around to O-P's code.  That bug
> (427468) is closed.

Any news from the orbit-list about the bug being valid and fixable/in the
process of fixing?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> Was the POA bug we identified fixed? You know, the one where deactivate
> doesn't clear out some fields on the servant's _private structure?

You mean the ORBit bug?  I added a work-around to O-P's code.  That bug
(427468) is closed.

Jason.

Re: [Orbit-python-list] Latest commits

[Christian R. R. <ki...@as...>]

On Mon, 28 May 2001, Jason Tackaberry wrote:

> > At this point there are no known leaks on either client or server side.
>
> Of course, this is only true if you're using ORBit 0.5.8, since 0.5.7
> and earlier has leaks with CORBA_TypeCode and CORBA_Any.

Was the POA bug we identified fixed? You know, the one where deactivate
doesn't clear out some fields on the servant's _private structure?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> At this point there are no known leaks on either client or server side.

Of course, this is only true if you're using ORBit 0.5.8, since 0.5.7
and earlier has leaks with CORBA_TypeCode and CORBA_Any.

Jason.

Re: [Orbit-python-list] Re: TestSuite2 (v0.01)

[Jason T. <ta...@li...>]

* Jason Tackaberry (ta...@li...) [010528 00:56]:
> verify failures?  Certain things should generate certain exceptions, and
> that needs to be verified.   For example, calling an orb function
> without initializing it should raise BAD_INV_ORDER, or passing bad
> values to objects should raise BAD_PARAM, and so on.

Nevermind.  I see that you are.  Awesome!

Jason.

Re: [Orbit-python-list] Implications of latest commits (your test suite)

[Jason T. <ta...@li...>]

> Let me freeze this here: What is supposed to happen if we never import
> Foo? Is _anything at all_ doable on the ref? What should it's __class__
> (and __dict__) say?

You won't be able to do much really, except invoke the base CORBA.Object
methods.  (Its __class__ would be CORBA.Object, and __dict__ would be
empty.)

> This happens when we do something like:
> 
> ns = orb.resolve_initial_references("NameService")
> 
> without importing CosNaming. I just wonder if a warning or something is in
> order in this case.

Right.  A warning isn't necessary.  The user will quickly figure out he
can't invoke on it. :)

Jason.

[Orbit-python-list] Re: TestSuite2 (v0.01)

[Jason T. <ta...@li...>]

> I'm testing it in the meantime, but just so you guys can feed me back on
> how awful it is. I'm off home now!

It's really pretty good. :)

Please remove the float test unless you can get it to work.  It's
annoying to report a failure when it's not really O-P's fault. :)

I'd like to see tests for servants by delegation and user exceptions
too.  (There's probably lots of other stuff missing, but these two are
just what I thought of off the top of my head.  Is it also possible to
verify failures?  Certain things should generate certain exceptions, and
that needs to be verified.   For example, calling an orb function
without initializing it should raise BAD_INV_ORDER, or passing bad
values to objects should raise BAD_PARAM, and so on.

Otherwise, it's an excellent start.  Also, is there a way to iterate
over a particular test, like in Roland's test suite?  It's quite useful
for checking for leaks.

Jason.

[Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

I went on a leak plugging frenzy tonight and along the way fixed a few
bugs too.  Roland, you'll be happy. :)

At this point there are no known leaks on either client or server side.
I plugged a few pretty obscure leaks, too.  Please file a bug if you
find more.

Jason.

[Orbit-python-list] Re: How should O-P handle references to deactivated objects

[Jason T. <ta...@li...>]

> Say we deactivate an object through poa.deactivate_object(). If references
> were generated to that object, what happens when we try and dereference
> them?

The correct behaviour would be for the ORB to raise
CORBA.OBJECT_NOT_EXIST.

> This is a cool thing to control because we can start handling on-demand
> startup of servants and that sort of thing. IIRC CORBA does account for
> this, but I don't know how it's done, really.

I know that OAF handles on-demand server loading.  I don't think there's
any provision for this in ORBit itself, but I could be wrong.

Jason.

[Orbit-python-list] Final Object patch

[Christian R. R. <ki...@as...>]

I've managed to sort out the reference creation/destruction stuff. This
now leaks 0 bytes. However, Roland's leaks will still go on because they
apparently occur in server.c/Portableserver.c. I will look into this
tomorrow a bit more.

One interesting thing is that I managed to crash the python interpreter
running tests interactively, but couldn't when running mass tests
automatedly. The SEGV happened inside Python-space, so I wonder if it
could be a bug in the interpreter?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Generic Fixes

[Christian R. R. <ki...@as...>]

Please review these patches:

object-diff is a fix for the creation of multiple python instances for a
single corba object (bad thing :-) there's also a DEBUG #ifdef so I can
make CFLAGS=-DDEBUG but if you hate it I'll kill it :-)

I've also added some stuff to pyclass__del (where we leak a whole lot).
Now this is never getting called. I've talked a bit more about this in
bug 427409.

except-diff is a fix for unhandled exceptions. I know it masks exceptions
we could identify by setting them to CORBA.UNKNOWN, but jesus, I had to
stop the SEGVs so my test suite would run.

server-diff includes fixes for memory leaked on deactivate and destroy,
and reorganizes the error checking just a bit. I've added some comments so
I can find myself in all this, too.

idl-diff is a single-line fix for a debug message where you had a
g_message before.

Roland, none of this fixes your leak. Sorry. We're leaking pretty bad
right now (4MB for 10000 runs here) but I'm gonna look at efence or
debauch..

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] How should O-P handle references to deactivated objects

[Christian R. R. <ki...@as...>]

Say we deactivate an object through poa.deactivate_object(). If references
were generated to that object, what happens when we try and dereference
them?

This is a cool thing to control because we can start handling on-demand
startup of servants and that sort of thing. IIRC CORBA does account for
this, but I don't know how it's done, really.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] TestSuite2 (v0.01)

[Christian R. R. <ki...@as...>]

I've started work on the test suite, borrowing from Roland's work, but
going farther into nitpicking. I've attached a dir that should be placed
inside orbit-python's main dir (which means it'll sit next to src/). Just
cd in and ./runtest.sh and I hope it'll work.

I'm testing it in the meantime, but just so you guys can feed me back on
how awful it is. I'm off home now!

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Implications of latest commits (your test suite)

[Christian R. R. <ki...@as...>]

On Fri, 25 May 2001, Jason Tackaberry wrote:

>    ior = open ("ior").readline ()
>    ref = orb.string_to_object (ior)
>    import Foo

Let me freeze this here: What is supposed to happen if we never import
Foo? Is _anything at all_ doable on the ref? What should it's __class__
(and __dict__) say?

This happens when we do something like:

ns = orb.resolve_initial_references("NameService")

without importing CosNaming. I just wonder if a warning or something is in
order in this case.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Implications of latest commits (your test suite)

[Jason T. <ta...@li...>]

Okay.  I fixed the particular segfault you reported when running your
test scripts.  However, the objref changes I made aren't completely
user transparent.  (Behaviour is more spec-compliant, mind you.)

For example, the old way allows this (what you were doing):

   module Foo {
      interface Bar {
         oneway void baz();
      };
   };
   
   import CORBA
   orb = CORBA.ORB_init ((), CORBA.ORB_ID)
   poa = orb.resolve_initial_references("RootPOA")
   
   ior = open ("ior").readline ()
   ref = orb.string_to_object (ior)
   import Foo
   ref.baz()


Note the last couple lines.  You're creating the reference _before_ the
ORB knows about module Foo.  ref becomes a CORBA.Object, but O-P still
lets you invoke on it, because according to the repo id of the object,
the operation exists, and so it goes ahead and marshals it.

With the new approach, you would either have to import Foo before
creating the objref, or _narrow() the object afterwards.  So:

   import Foo
   ref = orb.string_to_object (ior)
   ref.baz()

or:

   ref = orb.string_to_object (ior)
   import Foo
   ref = ref._narrow(Foo.Bar)
   ref.baz()

The old way may be more dynamic, but I think the current method is more
sane and predictable, and it behaves more like other ORBs.  In practice,
though, I doubt this will really be much of an issue.  And if it is, you
can use _narrow().

Jason.