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

David Konerding dek_ml@konerding.com
Thu, 29 Mar 2001 07:31:27 -0800


You'll see problems with exceptions if you don't use G++ compilers with the same
ABI.
For example, when I istalled Red Hat 7.0 and recompiled our big C++ app with G++
2.95.3
whenever we got an exception we got a bogus traceback for the throw, because Red
Hat 7.0's G++ compiler is a modified version (they call it 2.96 but that's really
a misnomer) which build different exception information.  When I recompiled the
whole app with their 2.96, lo and behold, it all worked
again.  Other things broke (such as STLport) which still needs to be understood.

As for -fomit-frame-pointer, I'd just as soon leave it out:
`-fomit-frame-pointer'
     Don't keep the frame pointer in a register for functions that
     don't need one.  This avoids the instructions to save, set up and
     restore frame pointers; it also makes an extra register available
     in many functions.  *It also makes debugging impossible on some
     machines.*


unless you never plan to debug the executable.  I don't know what effect it has
on exceptions.

Sai-Lai Lo wrote:

> The only reason why omniOrbORB::run() throws an OBJECT_NOT_EXIST is that it
> has been destroyed. Do you have a raise condition in your code? That is,
> the thread that calls orb->run() only got scheduled to run when another
> thread has already called destroy()?
>
> The uncaught exception error is worrying, as Stefan points out, it indicates
> that the compiler is not generating the correct exception handling table.
>
> Sai-Lai
>
> >>>>> ERIKSSON,TOBIAS (A-Sweden,ex1) writes:
>
> > 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
>
> --
> Sai-Lai Lo                                   S.Lo@uk.research.att.com
> AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com
> 24a Trumpington Street                Tel:   +44 1223 343000
> Cambridge CB2 1QA                     Fax:   +44 1223 313542
> ENGLAND