[omniORB] Server Shutdown on multi-processor machines

Alex Tingle alex.omniorb at firetree.net
Fri Mar 26 10:38:31 GMT 2004


I have a problem that may be related.

On Tru64 v5 on DEC alpha, we have applications that are coredumping when
they try to rethrow an exception. E.g.

  }
  catch(...) {
    cout<<"Whatever"<<endl;
    throw; //  <=== Core dump here
  }

-Alex Tingle

--
On Fri, 26 Mar 2004 11:01:38 +0100
Serguei Kolos <Serguei.Kolos at cern.ch> wrote:

> Hi
> I have similar problem using gcc-2.95.2.
> With gcc3.2 this never happens independently of which machine
> I'm using, i.e. single processor or dual.
> 
> Cheers,
> Sergei
> 
> Sharma, Ramesh wrote:
> 
> > I looked into it little further and seems like the problem is while 
> > destroying the omni_mutex
> >
> >  
> >
> > ++++++++++++++++++++++ posix.cc ++++++
> >
> > omni_mutex::~omni_mutex(void)
> >
> > {
> >
> >     THROW_ERRORS(pthread_mutex_destroy(&posix_mutex));
> >
> > }
> >
> > ++++++++++++++++
> >
> >  
> >
> > Looks like signal is raised from here and my signal handler catches
> > it and reports that as failure. Looks like some weird problem in 
> > multithreaded environment. Any suggestions on getting around it will
> > 
> > be really appreciated.
> >
> >  
> >
> > Thanks,
> >
> > Ramesh
> >
> > -----Original Message-----
> > From: omniorb-list-bounces at omniorb-support.com 
> > [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of
> > Sharma, Ramesh
> > Sent: Thursday, March 25, 2004 3:20 PM
> > To: omniorb-list at omniorb-support.com
> > Subject: [omniORB] Server Shutdown on multi-processor machines
> >
> >  
> >
> > Hi,
> >
> >  
> >
> > I am having following problem with CORBA 4.0.3 on Red-hat linux 7.1 
> > (client is compiled using gcc3.2 and server is compiled using 
> > gcc2.95.3 due to some avoidable reasons).
> >
> >  
> >
> > 1.      Things work fine on a machine which is single processor.
> >
> > 2.      Things don't work on multiprocessors machines. I  get a 
> > SIGSEGV while shutting down server.  Below is the segment of the
> > trace I got
> >
> >  
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > 0000 0000 0000 0000                     ........
> >
> > omniORB: POA(child) etherealising object root/child<0>
> > (deactivating).
> >
> > omniORB: omniRemoteIdentity deleted.
> >
> > omniORB: ObjRef(IDL:BlastSim/FaultSimFactory:1.0) -- deleted.
> >
> > omniORB: Preparing to shutdown ORB.
> >
> > omniORB: Destroying POA(RootPOA).
> >
> > omniORB: Destroying POA(child).
> >
> > omniORB: Deactivating all POA(child)'s objects.
> >
> > omniORB: Waiting for requests to complete on POA(child).
> >
> > omniORB: Requests on POA(child) completed.
> >
> > omniORB: Etherealising POA(child)'s objects.
> >
> > omniORB: Destruction of POA(child) complete.
> >
> > omniORB: Deactivating all POA(RootPOA)'s objects.
> >
> > omniORB: Waiting for requests to complete on POA(RootPOA).
> >
> > omniORB: Requests on POA(RootPOA) completed.
> >
> > omniORB: Etherealising POA(RootPOA)'s objects.
> >
> > omniORB: Stopping serving incoming endpoints.
> >
> > omniORB: throw giopStream::CommFailure from 
> > giopStream.cc:828(0,NO,COMM_FAILURE_UnMarshalArguments)
> >
> > omniORB: giopServer waits for completion of rendezvousers and
> > workers
> >
> > User time = 0:00:00(0) System time = 0:00:00(0) Memory usage = 
> > 4.18MDefault signal handler received SIGSEGV
> >
> >  
> >
> > Same exception gets thrown on both machines but on single processor 
> > machine the exception gets handled and server shuts down gracefully.
> > I am not sure why on multi-processor machines it is behaving 
> > differently. Is it the compiler version which might be making
> > difference?
> >
> >  
> >
> > Has anybody something like this?
> >
> >  
> >
> > Ramesh
> >
> >  
> >
> >--------------------------------------------------------------------
> >----
> >
> >_______________________________________________
> >omniORB-list mailing list
> >omniORB-list at omniorb-support.com
> >http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >  
> >
> 



More information about the omniORB-list mailing list