[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