[omniORB] _narrow problems with VAC++ 5.0 on AIX

[Sai-Lai Lo]

I guess this is omniORB 2.8.

>>>>> Peter Ledbrook writes:

> Hi,

> Much as I would like to give up supporting AIX, we are not allowed to.
> So, can anyone help with this problem.

> Part of an interface structure I have is:

>     ICapeNumericSolverComponent
>     ICapeNumericLAComponent : ICapeNumericSolverComponent
>     ICapeNumericLASystemFactory : ICapeNumericLAComponent

> Now, the client gets an object reference from a shared library that it
> loads in. This object reference is an implementation of the
> ICapeNumericLASystemFactory interface and has a repoID of:

>   "IDL:ICapeNumericLASystemFactory:1.0"

> The client then tries to narrow this to an
> ICapeNumericSolverComponent_ptr with a repoID of:

>   "IDL:ICapeNumericSolverComponent:1.0"

> This narrow fails though, and returns a _nil object reference. Stepping
> through the code of _realNarrow I see the following behaviour:

> void*
> omniObject::_realNarrow(const char* repoId)
> {
>   void* target = _widenFromTheMostDerivedIntf(repoId);  <<<<< This
> returns 0x00000000
  ^^^^^^^^^^^^^^^^^^^

  This is not right! I suspect there is something wrong in the way the
  compiler handle overloaded virtual function.

  Please set a breakpoint at 
      ICapeNumericLASystemFactory::_widenFromTheMostDerivedIntf.

 1. This function should be entered when _widenFromTheMostDerivedIntf is
    called.
 2. It should have taken the else branch and recursively called
      ICapeNumericLAComponent::_widenFromTheMostDerivedIntf.
 3. ICapeNumericLAComponent::_widenFromTheMostDerivedIntf should also
    recursively called
      ICapeNumericSolverComponent::_widenFromTheMostDerivedIntf
    which decides this is a match and returns the this pointer.

If the code doesn't do 1 to 3 then something is wrong with the generated
code. 

I also notice that you said "the client gets an object reference from a
shared library that it **loads in**". Do you mean the client program was
linked with the shared library or does the client program do a dlopen to
load the shared library? The later should also be suspected because the
global static initializers in the shared library may not be called.

Sai-Lai


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND