[omniORB] Why SYSTEM_EXCEPTION from _narrow()?

[David Morgenlender]

I'm using a version of omniORB from before the most recent snapshot.  My =
app was
working just fine re omniORB.  Then I modified the IDL file to break =
things down
into more interfaces.  I changed things around on both client & server to=
 use
the new interface definitions.  I rebuilt ... now I get a
CORBA::SYSTEM_EXCEPTION on the client!!!

This happens when it issues a _narrow(), essentially as follows:

  // Essentially the same as in the echo example ...
  CORBA::Object_var obj =3D getObjectReference(orb);	=09

  if( CORBA::is_nil(obj) )
  {
        cerr    << "  We have a nil object reference"  << endl;
        return FALSE;
  }

  // Get interface object references.
  DvtDiagnostics_var varDvtDiagnostics;
  varDvtDiagnostics =3D DvtDiagnostics::_narrow(obj);

I chased it down to GIOPCLIENT.CC line 245, where the "switch(rc)" goes =
to the
case for "GIOP::SYSTEM_EXCEPTION".  rc had been set by "rc <<=3D *this" =
on the
preceding line.

Digging a little further, I discovered that UMARSHAL(...) invokes
align_get_bytes() (BUFFEREDSTREAM.H line 371).  This returns the value of=
 p1,
which had been set to 0x1057684 & points to the value 2.  I tried tracing
through that code, but didn't understand what it's doing.

I'm coming up on a very tight client deadline, so if anybody has any idea=
 what's
going on here, I sure would like to hear about it!!!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Dave Morgenlender
e-mail: dmorgen@alum.mit.edu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D