[omniORB] omniORB 4.3: exceptionIdInAny config parameter

[pascal.moucheront at univ-eiffel.fr]

Hello,

I have compiled omniorb 4.3.0, as a dependency of another project
(https://gitlab.com/tango-controls/cppTango).

System:
- Debian 11 (bullseye)
- x64
- omniORB-4.3.0.tar.bz2 (2022-01-09 release from sourceforge)

This project has a test suite, and some tests fail when the remote object
throws an exception and omniORB exceptionIdInAny config parameter is one.
All tests succeed when this parameter is zero.

As my remote objects and client objects are freshly compiled and linked
with omniORB 4.3.0, and use only this ORB, I was puzzled that the value
of this 'interoperability' parameter should have any influence.

>From the information given in "#3.6.1 paragraph of the manual
(Exceptions in Anys), I tested in detail the marshaling/unmarshaling
of the exceptions:

- On the remote object side (server), the  the repository id of the
  exception is inserted into the buffer.
- On the client side, the repository id is also present in the buffer.

- When unmarshaling an exception in an Any, the repository id is extracted
a first time, in omniRemoteIdentity::dispatch function,

(orbcore/remoteIdentity.cc line 126)

    // Retrieve the Interface Repository ID of the exception.
    CORBA::String_var repoId(s.unmarshalRawString());

then, in the function fastCopyUsingTC called later from 
call_desc.userException(), it is extracted a second time

(dynamic/tcParser.cc line 203)

    CORBA::Any::PR_unmarshalExceptionRepoId(ibuf);

before trying to extract the exception members, which fails somwhere
in checkInputOverrun function with a MARSHAL system exception.

Commenting this line 203 suppressed the problem.

Is my assumption about 'exceptionIdInAny config parameter" exact ?

I focused on my use case only, and I'm not able to tell at omniORB scale
if it would be better to rewind the stream after the first extraction
or to avoid the second one.

Have a nice Day

Pascal