[omniORB] omniORBpy strangeness with structs

[Duncan Grisby]

On Tuesday 9 May, "Chris Knight" wrote:

> On the server side (written in Python) I would call the constructor for
> longs_struct, passing it floating point values (whoops) and return the
> newly-built struct.  Needless to say, the only error I got was on the client
> side, being: omniORB.CORBA.BAD_PARAM: Minor: 0, Completed: COMPLETED_MAYBE.
> 
> I traced the method on the server and found that it did, indeed, create the
> object and return it.  (So, effectively, it looks like only the client does
> typechecking.)  This caused me much confusion (taking me hours to trace
> down, thinking I was passing an invalid strings_struct into the function...)

In fact, both the client and server do type checking. The reason
you're seeing an exception on the client is that when the server tries
to marshal the struct, it throws the BAD_PARAM. The exception then
propagates to the caller. There isn't much else that can be done,
since it would be very bad to kill the server in such circumstances.

omniORB 3 prints exception throwing information with an ORB trace
level of 10 or more. Most omniORBpy exceptions weren't being reported
with this, but I've just checked in changes which enable it. Now you
get reports like:

  omniORB: throw BAD_PARAM from pyMarshal.cc:207

If you look at the code, you find:

  case CORBA::tk_float:
    {
      if (!(PyFloat_Check(a_o) || PyInt_Check(a_o))) AS_THROW_BAD_PARAM;

So you can see that it was trying to marshal a CORBA float, and would
have accepted either a Python Float or a Python Int, but got something
else.

You can get the patches from CVS, or wait for tomorrow's FTP snapshot.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --