[omniORB] NT Thread Question (updated)

[Dietmar May]

Hi Rob,

> When the win95 machine is acting as client, I can submit as many
commands as
> I wish, one at a time -- waiting for one thread to complete before
> submitting another.  Each thread will execute and terminate normally.
But I
> end up with a single memory leak.  When I submit two (or more)
commands
> without waiting for the first thread to complete, the first will
execute
> fine.  But I get a protection exception on the *second* thread with
the
> following trace-back:
> 
> KERNEL32! 77f1cd91()
> MSVCRT! 78008d93()
> OMNIORB25_RT! 1000e284()
> _proxy_Echo_Client::echoString(char * 0x0165faf0) line 465
> DoCmdThreadProc(void * 0x00cd1ef0) line 198
> _AfxThreadEntry(void * 0x0155fc88) line 113 + 13 bytes
> _threadstartex(void * 0x00cd2120) line 212 + 13 bytes
> 
> Where ......
> 
> void _proxy_Echo_Client::echoString ( const char *  mesg )
> {
>   CORBA::ULong _0RL_retries = 0;
> _0RL_again:
>   assertObjectExistent();
>   omniRopeAndKey _0RL_r;   <-----------------$$$$$ THIS IS LINE 465 in
the
> EchoSK file ... $$$$$
>   CORBA::Boolean _0RL_fwd = getRopeAndKey(_0RL_r);
>   CORBA::Boolean _0RL_reuse = 0;
> 
> And this is the result of calling-back the client method.

Seems to me I ran into a similar exception when first porting our server
code from Orbix to omniORB. We aren't using AfxThreadEntry, but rather
_beginthread.

I believe you're seeing an exception in the TCP/IP communications code
buried deep within omniORB. When we saw this problem, seems it was due
to either the client object not being ready, or no longer existing. In
effect, it is due to either an incomplete, or no longer existent, comm
link. (Sorry to be vague - we fixed it a long time ago).

First, I suggest ensuring that your client code executes a
boa()->obj_is_ready() call on the client object. I believe that this
requirement of omniORB does not conform to the CORBA standard
(obj_is_ready() appears to be the equivalent of impl_is_ready(), but for
per-object servers, and this usage is apparently non-standard;
nonetheless, it IS required by omniORB for any object which will service
*client* requests).

Second, though it may seem obvious (and redundant) to suggest this,
ensure that your client object still exists at the time of the second
call. 

Regards,
Dietmar