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

[ERIKSSON,TOBIAS (A-Sweden,ex1)]

In other words, it is a compiler error. But will it help if I like you
David, recompile g++ with whatever is the latest source for g++, are there
some tuning that needs to be done. And the problems you had with STL, have
you been able to see what that was, are the problems still there?

Strange thing is that I browsed GNU's home page the other day for GCC/G++
and couldn't really find anything about problems with exceptions, but on the
other hand I just browsed through the updates beeing done. Furthermore I
seem to have pretty much the latest version i.e. 2.95.2 20000220 (Debian
GNU/Linux)

/Tobias


-----Original Message-----
From: David Konerding [mailto:dek_ml@konerding.com]
Sent: den 29 mars 2001 17:31
To: Sai-Lai Lo
Cc: ERIKSSON,TOBIAS (A-Sweden,ex1); omniorb-list@uk.research.att.com
Subject: Re: [omniORB] Why isn't the exception thrown taken care of by
the catch(...)


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