[omniORB] MARSHAL from pyMarshal.cc

[Marco Ferreira]

Hi.

Could any kind soul tell me if this a result of a bug at omniORB code by
any chance?

omniORB: 2008-05-15 18:59:33.076226: throw MARSHAL from
pyMarshal.cc:3026 (NO,MARSHAL_InvalidEnumValue)

How could I correct this?

Thanks in advance...

[Duncan Grisby]

Post by Marco Ferreira
Could any kind soul tell me if this a result of a bug at omniORB code by
any chance?
omniORB: 2008-05-15 18:59:33.076226: throw MARSHAL from
pyMarshal.cc:3026 (NO,MARSHAL_InvalidEnumValue)

This means that you have received an enum that claims to have a numeric
value larger than the largest defined enum item. Almost certainly that's
because the sender and receiver are using different versions of the IDL.
Check that both sides of the communication have the same IDL.

Cheers,

Duncan.

[Marco Ferreira]

Thing is, I'm creating something like a proxy between the corba server and
the client, and when client connects directly to the server (no matter what
IDL version) there's no problem at all, but when I'm in the middle,
something goes wrong.
How is this possible?

Cheers

Post by Duncan Grisby

Post by Marco Ferreira
Could any kind soul tell me if this a result of a bug at omniORB code by
any chance?
omniORB: 2008-05-15 18:59:33.076226: throw MARSHAL from
pyMarshal.cc:3026 (NO,MARSHAL_InvalidEnumValue)

This means that you have received an enum that claims to have a numeric
value larger than the largest defined enum item. Almost certainly that's
because the sender and receiver are using different versions of the IDL.
Check that both sides of the communication have the same IDL.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- http://www.grisby.org --

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080515/ad5530ba/attachment.htm

[Marco Ferreira]

That was what I suspected, but unfortunately pyMarshel.cc still throws
that MARSHAL.
I'm sure both sides (including my proxy) have the same version. Could
there be any other reason for this?

Cheers

Post by Duncan Grisby

Post by Marco Ferreira
Could any kind soul tell me if this a result of a bug at omniORB code by
any chance?
omniORB: 2008-05-15 18:59:33.076226: throw MARSHAL from
pyMarshal.cc:3026 (NO,MARSHAL_InvalidEnumValue)

This means that you have received an enum that claims to have a numeric
value larger than the largest defined enum item. Almost certainly that's
because the sender and receiver are using different versions of the IDL.
Check that both sides of the communication have the same IDL.
Cheers,
Duncan.

[Marco Ferreira]

Sorry for all my mails, but this is really intriguing me.
I've been hacking the following piece of code in pyMarshal.cc, to try to
figure out what was happening at omniORB level:

static PyObject*
unmarshalPyObjectEnum(cdrStream& stream, PyObject* d_o)
{ // repoId, name, item list

char * string_ = PyString_AsString(PyObject_Repr(d_o));
printf("%s\n", string_);

PyObject* t_o = PyTuple_GET_ITEM(d_o, 3);

OMNIORB_ASSERT(PyTuple_Check(t_o));

CORBA::ULong e;
e <<= stream;

printf("e=%ld\n", e);

if (e >= (CORBA::ULong)PyTuple_GET_SIZE(t_o))
OMNIORB_THROW(MARSHAL, MARSHAL_InvalidEnumValue,
(CORBA::CompletionStatus)stream.completion());

PyObject* ev = PyTuple_GET_ITEM(t_o, e);
Py_INCREF(ev);
return ev;
}

And the output when the throwing occurs is:

(17, 'IDL:Incognito/SNMPVersion:1.0', 'SNMPVersion',
(SNMP_V_UNKNOWN, SNMP_V1, SNMP_V2, SNMP_V3))
e=-1075261268
omniORB: 2008-05-19 13:12:04.188990: throw MARSHAL from
pyMarshal.cc:3031 (NO,MARSHAL_InvalidEnumValue)

My question would be: how is it possible that 'e' value is below 0 since
it's declared as an unsigned long?

Post by Marco Ferreira
That was what I suspected, but unfortunately pyMarshel.cc still throws
that MARSHAL.
I'm sure both sides (including my proxy) have the same version. Could
there be any other reason for this?
Cheers

Post by Duncan Grisby

Post by Marco Ferreira
Could any kind soul tell me if this a result of a bug at omniORB code by
any chance?
omniORB: 2008-05-15 18:59:33.076226: throw MARSHAL from
pyMarshal.cc:3026 (NO,MARSHAL_InvalidEnumValue)

This means that you have received an enum that claims to have a numeric
value larger than the largest defined enum item. Almost certainly that's
because the sender and receiver are using different versions of the IDL.
Check that both sides of the communication have the same IDL.
Cheers,
Duncan.

[Marco Ferreira]

About the same file:

static PyObject*
unmarshalPyObjectEnum(cdrStream& stream, PyObject* d_o)
{ // repoId, name, item list

char * string_ = PyString_AsString(PyObject_Repr(d_o));
printf("%s\n", string_);

PyObject* t_o = PyTuple_GET_ITEM(d_o, 3);

OMNIORB_ASSERT(PyTuple_Check(t_o));

CORBA::ULong e;
e <<= stream;

cout << e << "\n";

if (e >= (CORBA::ULong)PyTuple_GET_SIZE(t_o))
OMNIORB_THROW(MARSHAL, MARSHAL_InvalidEnumValue,
(CORBA::CompletionStatus)stream.completion());

PyObject* ev = PyTuple_GET_ITEM(t_o, e);
Py_INCREF(ev);
return ev;
}

Result:

(17, 'IDL:Incognito/SNMPVersion:1.0', 'SNMPVersion',
(SNMP_V_UNKNOWN, SNMP_V1, SNMP_V2, SNMP_V3))
3219025932
omniORB: 2008-05-19 13:52:36.072857: throw MARSHAL from
pyMarshal.cc:3033 (NO,MARSHAL_InvalidEnumValue)

Note the extremely high value of 'e' variable.

Post by Marco Ferreira
Sorry for all my mails, but this is really intriguing me.
I've been hacking the following piece of code in pyMarshal.cc, to try to
static PyObject*
unmarshalPyObjectEnum(cdrStream& stream, PyObject* d_o)
{ // repoId, name, item list
char * string_ = PyString_AsString(PyObject_Repr(d_o));
printf("%s\n", string_);
PyObject* t_o = PyTuple_GET_ITEM(d_o, 3);
OMNIORB_ASSERT(PyTuple_Check(t_o));
CORBA::ULong e;
e <<= stream;
printf("e=%ld\n", e);
if (e >= (CORBA::ULong)PyTuple_GET_SIZE(t_o))
OMNIORB_THROW(MARSHAL, MARSHAL_InvalidEnumValue,
(CORBA::CompletionStatus)stream.completion());
PyObject* ev = PyTuple_GET_ITEM(t_o, e);
Py_INCREF(ev);
return ev;
}
(17, 'IDL:Incognito/SNMPVersion:1.0', 'SNMPVersion',
(SNMP_V_UNKNOWN, SNMP_V1, SNMP_V2, SNMP_V3))
e=-1075261268
omniORB: 2008-05-19 13:12:04.188990: throw MARSHAL from
pyMarshal.cc:3031 (NO,MARSHAL_InvalidEnumValue)
My question would be: how is it possible that 'e' value is below 0 since
it's declared as an unsigned long?

Post by Marco Ferreira
That was what I suspected, but unfortunately pyMarshel.cc still throws
that MARSHAL.
I'm sure both sides (including my proxy) have the same version. Could
there be any other reason for this?
Cheers

Post by Duncan Grisby

Post by Marco Ferreira
Could any kind soul tell me if this a result of a bug at omniORB code by
any chance?
omniORB: 2008-05-15 18:59:33.076226: throw MARSHAL from
pyMarshal.cc:3026 (NO,MARSHAL_InvalidEnumValue)

This means that you have received an enum that claims to have a numeric
value larger than the largest defined enum item. Almost certainly that's
because the sender and receiver are using different versions of the IDL.
Check that both sides of the communication have the same IDL.
Cheers,
Duncan.

[Duncan Grisby]

Post by Marco Ferreira
Thing is, I'm creating something like a proxy between the corba server
and the client, and when client connects directly to the server (no
matter what IDL version) there's no problem at all, but when I'm in
the middle, something goes wrong.
How is this possible?

That suggests that the proxy has seen different IDL to the client and
server. The proxy has to unmarshal and then remarshal the call
arguments, so it must have the right IDL.

Duncan.

[Duncan Grisby]

On Monday 19 May, Marco Ferreira wrote:

[...]

Post by Marco Ferreira
(17, 'IDL:Incognito/SNMPVersion:1.0', 'SNMPVersion',
(SNMP_V_UNKNOWN, SNMP_V1, SNMP_V2, SNMP_V3))
3219025932
omniORB: 2008-05-19 13:52:36.072857: throw MARSHAL from
pyMarshal.cc:3033 (NO,MARSHAL_InvalidEnumValue)
Note the extremely high value of 'e' variable.

Clearly the value unmarshalled is not an enum value at all. It is some
other data that, when interpreted as an unsigned long, has the large
value you see. (By the way, the reason your previous test showed a
negative number is that you used a %d format, which expects a signed
integer value.)

The only reasonable explanation is that the receiver has different IDL
to the sender, so the receiver is interpreting the marshalled data
incorrectly.

You might gain some insight by running with -ORBtraceLevel 40 which will
output the complete contents of all GIOP messages. You can hunt for the
number you're seeing, which in hex is BFDE700C, to see the context it is
in. If you're using a little-endian machine, it will appear reversed, as
0C70DEBF.

Cheers,

Duncan.