oops - sorry about that (dang email editor)
Anways, the bug is in poamediator.cc line 677
 
replace the line...
if (inf.pstate != Active && inf.pstate != Stopped &&
 
with this...
---------------------
if (inf.pstate==Active) {
  CORBA::Address *addr= (CORBA::Address *) inf.ior.addr();
  assert (addr)
 
  CORBA::ORBMsgId tempOrbMsgId=orb->new_orbid(orb->new_msgid());
  requests[tempOrbMsgId]=id;
  CORBA::ORBMsgId orbid=orb->bind_async(repoid, tag, addr, this, tempOrbMsgId);
  assert(orbid!=0);
  return TRUE;
}
else if (inf.pstate != Active && inf.pstate != Stopped &&
-------------------------------------
 
I know this isn't a complete fix (as the other states of inf.pstate are not 
considered), but it stops the problem.  Seems that if the server is active and 
running, then this section is skipped - then multiple messages are generated 
and sent to all the object adapters in svmap (which is why the other adapters 
crashed while the server that was desired continued to work).
 
I'd love it if this fix (or something similar) is included in the next mico - I 
don't know how to do that (I'm also not an official developer so I don't think 
I can submit a bug fix).
Mark

--- On Tue, 7/21/09, Karel Gardas <kgar...@objectsecurity.com> wrote:


From: Karel Gardas <kgar...@objectsecurity.com>
Subject: Re: [mico-devel] imr issue
To: "Mark Richardson" <markm...@yahoo.com>
Cc: mico-devel@mico.org
Date: Tuesday, July 21, 2009, 12:25 PM


Mark Richardson wrote:
> Hi all,
> I've been playing with the imr (again for all that have seen my posts 
> before), and I found an interesting bug. The REALLY interesting part is that 
> mico 2.3.7 doesn't have this problem while 2.3.11, 2.3.12, and 2.3.13 do 
> (currently using 2.3.13)!
>  
> I have a simple client & server that I use and they work just fine.  When 
> creating the imr entry I use the following command...
> imr create ImrTestInterfaceServer poa "/mylocation/ImrTestServer" 
> IDL:ImrTestInterface:1.0#ImrTestInterfaceServer -ORBImpRepoAddr 
> inet:myMachine:2345
>  
> Then, I create multiple instances on the imr...
> imr create ImrTestInterfaceServer0 poa "/mylocation/ImrTestServer 0" 
> IDL:ImrTestInterface:1.0#ImrTestInterfaceServer0 -ORBImpRepoAddr 
> inet:myMachine:2345
> imr create ImrTestInterfaceServer1 poa "/mylocation/ImrTestServer 1" 
> IDL:ImrTestInterface:1.0#ImrTestInterfaceServer1 -ORBImpRepoAddr 
> inet:myMachine:2345
>  
> If I use the client to communicate with just one of them everything is fine.  
> But if I do this...
> 1. new client connects to the original (ImrTestServer)
> 2. disconnect & exit client (ImrTestServer still running)
> 3. new client connects to ImrTestServer0
> 4. disconnect & exit client (ImrTestServer0 still running)
> 5. new client connects to ImrTestServer1
> 6. disconnect & exit client (ImrTestServer1 still running)
> ------ everything up till now is good -----
> 7. new client connect to the original (ImrTestServer)
>  
> Then sometimes it works fine (if I restarted micod just before this), but 
> most of the time ImrTestServer0 crashes.  Sometimes I even get ImrTestServer1 
> to crash.
>  
> The error that I get from the micod is...
> ImrTestServer: mt_dispatcher.cc:124: virtual void 
> MICO:MTDispatcher::process(MICO::seg_type*): Assertion '_msg->conn->state() 
> == MICOMT:StateRefCnt::Terminated' failed
>  
> I always will get this if I repeat steps 1-6 enough (I've never gotten all 
> the way through 2 times).  80% of the time the other 2 servers that are not 
> being accessed by the client crash.
>  
> I've just started debugging, but it's gonna take me a while because I'm not 
> that familar with the MTdispatcher.  Anyone out there got any ideas?

It would be nice to see all threads stack dump of the crashed process
and also of the micod. Without it, it's hard to make any hint for
further debugging.

Cheers,
Karel
-- 
Karel Gardas                  kgar...@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com



      
_______________________________________________
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel

Reply via email to