[omniORB] Location Marshalling Fault

[EXT-Pennington, Dale K]

I am taking a CORBA application that ran on another ORB and porting it
to OmniOrb. It includes a rather involved structure as one of the
parameters. When I attempt to test the function take uses this
structure, I get a Marshal Exception with a minor code that tranlates to
: MARSHAL_InvalidEnumValue. Is there any way to get OmniORB to give me
more details (if I new which structure member it would help a lot in
tracking the issue down).

Thanks,
Dale Pennington

[Duncan Grisby]

Post by EXT-Pennington, Dale K
I am taking a CORBA application that ran on another ORB and porting it
to OmniOrb. It includes a rather involved structure as one of the
parameters. When I attempt to test the function take uses this
structure, I get a Marshal Exception with a minor code that tranlates to
: MARSHAL_InvalidEnumValue. Is there any way to get OmniORB to give me
more details (if I new which structure member it would help a lot in
tracking the issue down).

If you run with -ORBtraceExceptions 1 you'll get a message telling which
line in the stub header file has thrown the exception. Looking at that
code will tell you which enum it is that's been sent with an invalid
value, but not which structure it's in.

To work that out, the easiest thing is to modify the generated code that
throws the MARSHAL exception so that it calls abort(). That way your
program will fail at the time the invalid value occurs, and you'll be
able to figure out which structure it's in from the call stack.

Cheers,

Duncan.

[EXT-Pennington, Dale K]

Thank you, that allowed my to track down what is doing on and confirm my
suspicions.

Basically, we are interfacing to an existing CORBA application that does
things I am not sure should be done.

They are placing arbitrary values into enumated members of a CORBA IDL
derived structure and passing it through the CORBA interface. These
values fail the sanity check in the generated .hh files while
unmarshalling in the server, hence causing the CORBA MARSHALLING
exception to be passed back to the client.

Now we are in no position to change how the existing app does things.
Also what they do gets by their ORB (as well as TAO orb, which we are
also evaluating) with no complaints. Sanity checking seems unique to
OmniORB at this point.

The next question on my list is : Is there a way to disable the sanity
checking in the enumation unmarshalling code, other than manually
editing the .hh files generated by the IDL Compiler. I read the IDL
chapter of the documentation, and did not see anything.

Thanks,
Dale Pennington

-----Original Message-----
Sent: Monday, July 21, 2008 10:13 AM
To: EXT-Pennington, Dale K
Subject: Re: [omniORB] Location Marshalling Fault

Post by EXT-Pennington, Dale K
I am taking a CORBA application that ran on another ORB and

porting it

Post by EXT-Pennington, Dale K
to OmniOrb. It includes a rather involved structure as one of the
parameters. When I attempt to test the function take uses this
structure, I get a Marshal Exception with a minor code that

tranlates

Post by EXT-Pennington, Dale K
to
: MARSHAL_InvalidEnumValue. Is there any way to get OmniORB

to give me

Post by EXT-Pennington, Dale K
more details (if I new which structure member it would help

a lot in

Post by EXT-Pennington, Dale K
tracking the issue down).

If you run with -ORBtraceExceptions 1 you'll get a message
telling which line in the stub header file has thrown the
exception. Looking at that code will tell you which enum it
is that's been sent with an invalid value, but not which
structure it's in.
To work that out, the easiest thing is to modify the
generated code that throws the MARSHAL exception so that it
calls abort(). That way your program will fail at the time
the invalid value occurs, and you'll be able to figure out
which structure it's in from the call stack.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- http://www.grisby.org --

[Duncan Grisby]

Post by EXT-Pennington, Dale K
They are placing arbitrary values into enumated members of a CORBA IDL
derived structure and passing it through the CORBA interface. These
values fail the sanity check in the generated .hh files while
unmarshalling in the server, hence causing the CORBA MARSHALLING
exception to be passed back to the client.

That is definitely an invalid thing to do. The only permitted values for
an enum are the ones implied by the enum's definition in IDL. Sending
any other numeric value is an error, and it's right for omniORB to throw
an exception.

It is a coincidence that the C++ mapping to C++ enum permits numeric
values other than the enum values -- other language mappings, for
example Python, use symbolic names for the enum values, and cannot
possibly support values outside those in the IDL.

Post by EXT-Pennington, Dale K
Now we are in no position to change how the existing app does things.
Also what they do gets by their ORB (as well as TAO orb, which we are
also evaluating) with no complaints. Sanity checking seems unique to
OmniORB at this point.

omniORB is often more strict about following the specifications than
other ORBs.

Post by EXT-Pennington, Dale K
The next question on my list is : Is there a way to disable the sanity
checking in the enumation unmarshalling code, other than manually
editing the .hh files generated by the IDL Compiler. I read the IDL
chapter of the documentation, and did not see anything.

There's no omniidl switch, and I don't think it's good to add one and
encourage people to do invalid things like this. That said, it's really
easy for you to modify the omniidl back-end to remove the checking code.
Look at src/lib/omniORB/omniidl_be/cxx/header/template.py, line 1577, in
the definition of enum_operators. If you edit that to remove the check,
that will prevent it being generated.

If you don't fancy that approach, the other thing you can do is change
the IDL to use an unsigned long instead on an enum. As long as the
values aren't put inside Anys, the marshalled form will be identical.

Cheers,

Duncan.