[omniORB] VC++ 5: omniORB Mishandling Exceptions! Other errors!

David Morgenlender dmorgen@alum.mit.edu
Mon, 18 May 1998 21:19:51 GMT


I'm in the process of trying to get omniORB working as a CORBA server =
under
ETS-Kernel (a realtime OS from PharLap).  The ETS-Kernel development =
environment
uses Visual C++ 5.  It provides a Win32 API, Winsock API, etc.

My current test environment consists of a client server app running under
ETS-Kernel;  the app is based upon the EG3_IMPL (echo #3 example
implementation).  This system is connected to a Win95 system via TCP/IP. =
 The
omniORB name service is running on the Win95 system.

I'm having trouble getting the server app running.  It seems to hang;  =
but after
many minutes, Dev Studio reports "unhandled exception in app.exe 0x... =
Access
Violation".  I chased this down to an error in memmove(), which is called=
 from
the ...received() function at line #127 in RelStream.cc;  memmove is =
called with
a huge size value.  But this is just the tip of the iceberg!

Taken from the top, this is what's happening:  in NamingSK.CC, the =
function
COSNaming::_proxy_NamingContext::bind_new_context() calls =
_ORL_C.ReceiveReply()
(GIOP_C::ReceiveReply()).  This returns an "Already Bound" error.  The =
error
handling code for this error, does a "throw _ORL_ex".  However, execution
continues at the first catch in this function.  The first assembly =
instruction
here is a jump to beyond all the catches.  The first statement there is  =
"goto
_ORL_again", which goes to the top of the function.  Now when
_ORL_C.ReceiveReply() is called it has the problems described above.

This leads to 3 questions:

1.  Why is the Already Bound error generated?

2.  Why does the thrown exception in the Already Bound error handler not =
throw
an exception & return from this function?

3.  Why is memmove() called with erroneous parameters?

I've traced through the 2nd GIOP_C::ReceiveReply() call, which generates =
the
exception after many minutes.  It detects a "wrong header".  But when it =
throws
an exception, processing continues inline.  It eventually  issues "return
this->ReceiveReply()".  The memmove() exception happens somewhere before =
this
function call returns.

Does anybody have any idea what's going on here?  Why the initial error, =
which
generates an exception?  Why the incorrect exception handling by the =
compiler?

=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