[omniORB] NT Thread Question (updated)

[Robert H. Fritz]

Hi Everyone,

This is a follow-up to a question I submitted last week.  Thanks to everyone
who responded.  I've gotten partial but unusual results.  To recap, I've got
a Win95 machine running as a client and an NT40 workstation acting as a
server.  The client is calling a oneway method on the server and passing an
object reference (of itself) to the server.  When the server-method
completes, the server callsback a client-method using this object reference.

This arrangement worked fine until I re-implemented the server method using
AfxBeginThread.

Here's the behavior:

When client and server are both running local to the NT40 machine, the
client can run submit multiple simultaneous-commands to the server.  All
server threads begin and end normally.  No problems.

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.

So my minor problem is what could be the source of the server memory leak
when called
from a "foreign" client.  Should I release the CORBA::strdup()?  But my
major problem is what is
the source of the exception ...

Any info appreciated.

Rob Fritz
rfritz@geologics.com

The relevant code is relatively simple:

// An item of this type is passed to the thread.
//
typedef struct
{
	Echo_Client_ptr  m_rcEchoClient;
	const char *m_lpszcmd;
} tCDoCmdThreadInfo;

// This is the oneway server method invoked by the client
//
void
Echo_Server_i::doCMD ( Echo_Client_ptr  ar_cEchoClient, const char *
 as_cmd )
{
tCDoCmdThreadInfo *lpDoCmdThreadInfo;
Echo_Client_ptr  lr_cEchoClient = Echo_Client::_duplicate(ar_cEchoClient);
char *lpsz_cmd = CORBA::string_dup(as_cmd);

	// repackaging required for AfxBeginThread
            //
	lpDoCmdThreadInfo = new tCDoCmdThreadInfo;

	lpDoCmdThreadInfo->m_rcEchoClient = lr_cEchoClient;
 	lpDoCmdThreadInfo->m_lpszcmd = lpsz_cmd;

	AfxBeginThread (DoCmdThreadProc, lpDoCmdThreadInfo);
}

// This is the real method body.
//
UINT DoCmdThreadProc(LPVOID pParam)
{
tCDoCmdThreadInfo* pDoCmdInfo = (tCDoCmdThreadInfo*)pParam;

 // Actual method stuff here

// Now we're done.  Callback to the client.
// Second "foreign" thread generates protection exception here.
//
pDoCmdInfo->m_rcEchoClient->echoString (lsz_cmd);

// Release duplicated obj reference
CORBA::release (pDoCmdInfo->m_rcEchoClient);

// Allocated by DoCMD
delete pDoCmdInfo;

  return 0;
}