[omniORB] Why isn't the exception thrown taken care of by the catch(...)

ERIKSSON,TOBIAS (A-Sweden,ex1) tobias_eriksson@agilent.com
Thu, 29 Mar 2001 09:17:24 +0200


Unfortunately I'm not using that flag.  The compile line looks like this;
(basically for all files)

g++ -Wall -D_REENTRANT -fpic -DPORT=\"Linux2.2c6_x86\" -I. -I..
-I/ComOpt/Development/CellOpt/AFP/2.3
-I/ComOpt/Development/CellOpt/AFP/2.3/corba/omniORB3/include
-DJAVA_LONG_THIRTYTWO -DREQUIRE_RAND_R -DREQUIRE_CTIME_R -DACCEPT_UNSIGNED
-DUSE_SIGCHLD_HANDLER -DUSE_POSIX_SIGNALS -DNODATABASE
-DBIN_DIR=\"/usr/local/CellOpt/cellopt-core-1.7/bin/Linux2.2c6_x86\"
-DAPP_VERSION=\"2.3\" -DAPP_VERSION_SHORT=\"23\" -DSERVER_REV_MAJOR=1
-DSERVER_REV_MINOR=0 -DSERVER_REV_PATCH=12 -DSERVER_MESSAGE=\""Agilent
licensing"\" -DMAX_CLIENTS=50 -DSERVER_PORT=8088 -DCORE_REV_MAJOR=1
-DCORE_REV_MINOR=7 -DCORE_REV_PATCH=22
-DLOG_PATH=\"/usr/local/CellOpt/log\"
-DLOG_NAME=\"CellServ.1.7.22.Linux2.2c6_x86\" -DLICENSE_SERVER -D__linux__
-D__x86__ -D__OSVERSION__=2 -D__OMNIORB3__
-I/ComOpt/Development/CellOpt/AFP/2.3/flexlm/v7.0/machind -DFLEXLM
-DFLEXLM_HEARTBEAT_RECONTIME=10	 -DFLEXLM_HEARTBEAT_MAXRECON=2
-DFLEXLM_HEARTBEAT_MAXFAIL=2	 -Wno-return-type	
		 -DDEBUG -g -c -o Linux2.2c6_x86/g/EventQ.o EventQ.cpp

 Regards
  Tobias

-----Original Message-----
From: Stefan Seefeld [mailto:seefeld@sympatico.ca]
Sent: den 28 mars 2001 16:37
To: omniorb-list@uk.research.att.com
Subject: Re: [omniORB] Why isn't the exception thrown taken care of by
the catch(...)


ERIKSSON,TOBIAS (A-Sweden,ex1) wrote:

> Hi 
>  I've had this problem a couple of times, but I don't seem to be able to
> figure out what it is.
> As I run my application it all by a sudden receives an exception (all
> according to the stack trace below), what is causing it? The stack trace
> says __throw but why doesn't my catch(...) take it? Instead it terminates.

I remember having had a similar problem a while ago. I think it was a 
bug in gcc, specifically,
gcc not being able to deal with exceptions correctly when 
-fomit-frame-pointer (something like that, anyway)
was given.

If you have that option, or just use any kind of optimization, you may 
want to recompile without it
and see whether this makes a difference. The bug I'm talking about was 
reported to the gcc mailing list...

hope this helps,    Stefan