[omniORB] unexpected exception (not a CORBA exception)
Xuekai Song
kai@ptc.com
Wed, 19 Jul 2000 09:42:02 -0400
Duncan,
Thanks for the reply.
I finally managed to track down the problem after looking into the
various
potential causes.
The problem was due to the use of /MD compiler option and the third party
library. In my test I used the basic echo example and it works ok
without
linking the third party library. But when the third party library is
linked with
the example, the exception happens although no function has been called
from
the thrid party library.
This is some of the link options I used:
link /NODEFAULTLIB msvcrt.lib msvcirt.lib third_party.lib
Here the third party lib are import lib and its DLL are loaded at
runtime.
And the problem was caused due to handling of the default libraries in VC
for multi-threaded applications.
Now none of the problems as described in my previous email exist.
Cheers,
Xuekai
---
Duncan Grisby wrote:
> On Friday 7 July, Xuekai Song wrote:
>
> > a) Each time after a call is returned from the server to the
> > client, the following exception was thrown:
> >
> > omniORB: WARNING -- method 'IlUserAuthenticate' raised an
> > unexpected exception (not a CORBA exception).
> > omniORB: An exception has occured and was caught by tcpSocketMT
> > Worker thread.
> >
> > Here method IlUserAuthenticate(const char *, const char *) returns
> > boolean type. The same exception was thrown for other calls made to
> > the third party library. Apart from the exception, it works ok.
>
> The most likely explanation is that your function really is throwing a
> non-CORBA exception. I think Windows turns some things like
> out-of-memory into C++ exceptions, so maybe that's the problem. Try
> putting a try block which catches (...) around your function, and see
> if it catches anything.
>
> The only other possibility I can think of is that there's a compiler
> version mismatch. Are you using the Windows binary distribution? That
> is compiled with VC++ 5, so it might be the cause of the problem.
>
> > b) Each call from the client takes about the same time as set by
> > -ORBserverCallTimeoutPeriod. So it means I have to set it
> > to 1 in order to get the fastest response possible.
> >
> > a) & b) might be related and it seems to me that the server
> > somehow lost track of the client request and have to wait until
> > the connection to be timed out.
>
> That's very odd. After the "unexpected exception" message, it should
> throw a CORBA::UNKNOWN exception to the caller, without waiting for
> anything. Try running your server with a command line argument of
> -ORBtraceLevel 20, and see what the trace messages say.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --