[omniORB] giopServer pd_state ZOMBIE for RootPOA (when giopServer TIMEDOUT before)

[Martin Trappel]

Martin Trappel wrote:
> Martin Trappel wrote:
>> [omniORB 4.1.2, Windows XP, VC8 prebuilt DLLs]
>>
>> I have the situation where I repeatedly initialize and destroy the ORB
>> in a client application, (...)
>  >
> 
> I have now been able to reproduce the problem in a simpler context.
> Consider the following IDL:
> interface Dummy {
>     void echo(in string s);
> };
> interface DummyServer {
>   void doEcho(in Dummy d);
> };
> 
> DummyServer is called by the process running a Dummy instance and the 
> doEcho method just calls echo on the given interface pointer.
> 
> And this is the setup I'm using:
> A.) Start a process with an instance of DummyServer (and register the 
> object with the naming service). The server will just keep running and 
> do nothing else. (just as with the echo example)
> 
> B.) The Client Process now does the following *in a loop*:
> 1.) ORB_init
> 2.) start a separate omni_thread and call orb->run() there
> 3.) create  a new poa from the root poa with the same policies as the 
> root poa
> 4.) Create a new Dummy impl object
> 5.) activate the object with the created POA
> 6.) activate the POA
> 7.) Resolve the DummyServer Object via NamingService
> 8.) Call dummy_srv_ref->doEcho(my_dummy->_this())
> 9.) deactivate POA + destroy POA
> 10.) shutdown(true) orb (afterwards wait for run thread to terminate)
> 11.) destroy() orb
> 
> With this setup I will reliably hit
> Caught omniORB::fatalException:
>   file: giopServer.cc
>   line: 284
>   mesg: pd_state != ZOMBIE
> after just a few iterations (sometimes even on the first one).
> (...)

As a crosscheck I have tried to orb->run() in the same thread as 
ORB_init() was called (and launch the server call in a separate thread 
instead) -- error still there.

During this I found that if I introduce a slight delay (Sleep_100ms) 
before orb->shutdown(true) (step 10) the error is no longer reproducible.

I'll keep you posted if I find something more ...

br,
Martin