[omniORB] Why would resolve_initial_references() be throwing InvalidName

[Mark Johnson]

We figured out the fix.  It appears to be a problem with the compiler, =
when
we downgraded go gcc 2.95 (from 2.96) all the problems went away.  =
Another
symptom of our problem was that any exception throw by omniORB would =
cause a
SIGSEGV signal.=20

-----Original Message-----
From: Mark Johnson=20
Sent: Thursday, March 28, 2002 4:39 PM
To: 'OMNIORB Mailing List (E-mail)'
Subject: RE: [omniORB] Why would resolve_initial_references() be
throwing InvalidName


Here's some more info:

Stepping through the application in gdb shows that right after the =
exception
is thrown a SIGSEGV is raised:

	Program received signal SIGSEGV, Segmentation fault.
	__strtol_internal (nptr=3D0x4069bedc "=AE\211=E8@=E8=A9=E8@=D0=BEi@", =
endptr=3D0x0,
base=3D1080672056, group=3D1074851824) at eval.c:36
	36      eval.c: No such file or directory.
        in eval.c
	Current language:  auto; currently c

Here is the stack trace:

	0  __strtol_internal (nptr=3D0x4069bedc =
"=AE\211=E8@=E8=A9=E8@=D0=BEi@", endptr=3D0x0,
base=3D1080672056, group=3D1074851824) at eval.c:36
	#1  0x40680658 in __user_type_info::dyncast (this=3D0x4069bedc,
boff=3D0, target=3D@0x4069bf38, objptr=3D0x4010eff0, =
subtype=3D@0x4069bec8,=20
    subptr=3D0x4010eff0) from /usr/lib/libstdc++-libc6.2-2.so.3
	#2  0x406820f3 in __dynamic_cast_2 (from=3D0x40e86810 <__si_type_info
type_info function>,=20
    to=3D0x40691540 <__pointer_type_info type_info function>, boff=3D0,
address=3D0x4010eff0,=20
    sub=3D0x40e86aac <type_info type_info function>, =
subptr=3D0x4010eff0) from
/usr/lib/libstdc++-libc6.2-2.so.3
	#3  0x40681eb3 in __is_pointer (p=3D0x4010eff0) from
/usr/lib/libstdc++-libc6.2-2.so.3
	#4  0x40681506 in __cp_pop_exception (p=3D0x81ca6d8) from
/usr/lib/libstdc++-libc6.2-2.so.3
	#5  0x080ea8ce in CosNameEx::init (this=3D0xbffff450, =
aOrb=3D0x81c7f70,
aNameService=3D@0xbffff4e0) at common/CosNameEx.cpp:96
	#6  0x080ea0e0 in CorbaManager::bind (this=3D0x81c2490,
aUri=3D0xbffff570, aObjRef=3D0x81c9eb0) at common/CorbaManager.cpp:119
	#7  0x08106a65 in ThreadInfo::createServant (aName=3D0xbffff5d0) at
threads/ThreadInfo.cpp:268
	#8  0x0810675f in ThreadInfo::createServant (argc=3D7,
argv=3D0xbffff8d4) at threads/ThreadInfo.cpp:233
	#9  0x080d8565 in main (argc=3D7, argv=3D0xbffff8d4) at main.cpp:194
	#10 0x406db507 in __libc_start_main (main=3D0x80d82d0 <main>, =
argc=3D7,
ubp_av=3D0xbffff8d4, init=3D0x80d2be0 <_init>,=20
	    fini=3D0x8150a54 <_fini>, rtld_fini=3D0x4000dc14 <_dl_fini>,
stack_end=3D0xbffff8cc) at ../sysdeps/generic/libc-start.c:129

Does the trace mean anything to anyone?

Here is CosNameEx.cpp:

bool CosNameEx::init( CORBA::ORB_ptr aOrb, const std::string & =
aNameService
)
{
   if( CORBA::is_nil( aOrb ) )
      return false;
=20
   try
   {
      // Obtain a reference to the root context of the Name service:
      CORBA::Object_var obj =3D aOrb->resolve_initial_references(
aNameService.c_str() );

      if( CORBA::is_nil(obj) )
         return false;
 =20
      // Narrow the reference returned.
      theRootContext =3D CosNaming::NamingContext::_narrow(obj);
      if( CORBA::is_nil(theRootContext) )
         return false;
   }
   catch( CORBA::ORB::InvalidName& )
   {
      // This should not happen!
      std::cout << "ctrlr: caught InvalidName exception on
resolve_initial_references(\"" << aNameService << "\")" << std::endl;

      return false;  // <<<< here is line 96
   }

   return true;
}

-----Original Message-----
From: Mark Johnson=20
Sent: Thursday, March 28, 2002 4:10 PM
To: 'OMNIORB Mailing List (E-mail)'
Subject: [omniORB] Why would resolve_initial_references() be throwing
InvalidName


ENV: Red Hat 7.1 (kernel 2.4.7-10), g++ 2.96, omniORB3.0

We have the same code compiled for Solaris, Mandrake, and Red Hat.  The
nameserver is running on the solaris machine.  The instances running on
Solaris and Mandrake run fine, but when the instance is started on the =
Red
Hat machine, it throws and InvalidName exception.

All the applications are all started with the following command line:

	./ctrlr -ORBInitRef AUST-1=3Dcorbaname::neutron -ORBtraceLevel 20

The app on Red Hat says that AUST-1 is not a valid name in the call to
resolve_initial_references().  I can't figure out what would be the =
problem
here.  Is there anything that I can double check to determine why this =
would
be happening.

Here's is the trace from omniorb:

omniORB: strand Ripper: start.
omniORB: scavenger : start.
omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6=20
omniORB: Initialising omniDynamic library.
omniORB: Initialising incoming rope factories.
omniORB: strand Rope::incrRefCount: old value =3D 0
omniORB: Starting incoming rope factories.
omniORB: tcpSocketMTfactory Rendezvouser: start.
omniORB: tcpSocketMTfactory Rendezvouser: block on accept()
omniORB: Activating: root<0>
omniORB: Creating ref to local: root<0>
 target id      : IDL:Controller:1.0
 most derived id: IDL:Controller:1.0
omniORB: createObjRef -- reusing reference from local ref list.
ctrlr: trying to bind to: AUST-1
omniORB: resolve_initial_references throws CORBA::ORB::InvalidName
ctrlr: caught InvalidName exception on =
resolve_initial_references("AUST-1")
omniORB: scavenger : scanning connections