[ace-users] problems with execptions in gcc-2.95.x using ACE (+TAO)
David Philippi
I've got a problem with throwing exceptions in gcc-2.95.x. The source
compiles and links without any errors and a small testprogramm throwing
exceptions also worked flawless. But in my app using ACE+TAO I get a segfault
whenever an exception is thrown with an IMO very strange backtrace:
#0 0x40a680b1 in kill () from /lib/libc.so.6
#1 0x40a67ed1 in raise () from /lib/libc.so.6
#2 0x40a6942c in abort () from /lib/libc.so.6
#3 0x401c531b in __default_terminate () from
/usr/src/ACE_wrappers/ace/libACE.so
Current language: auto; currently c
#4 0x401c533c in __terminate () from /usr/src/ACE_wrappers/ace/libACE.so
#5 0x401c5f4e in __throw () from /usr/src/ACE_wrappers/ace/libACE.so
I don't understand why __throw should be from libACE.so and why __terminate
is called without any chance to catch the exception first. I can't even catch
it in a try block around the function throwing the exception.
I can't imagine that my code should have a bug, since the very same code
works if I compile ACE+TAO and my app using gcc-3.0.3 or above. Unfortunatly
gcc-3.x is quite buggy and even compiling ACE+TAO using "optimize=0 inline=0"
doesn't fix all the problems I've encountered - I've got still mutex locks
not held anymore without calls to release, pointers changing to 0 or even
denoting objects of another class (not derived from the right one)...
I've tried with
- ACE 5.2.1 / TAO 1.2.1 and 5.2.2 / 1.2.2
- gcc-2.95.2.1 and gcc-2.95.3
- gcc-3.0.3 and recent beta releases
- binutils 2.11.92.0.12
- glibc 2.2.90
My linux is an RedHat 7.1 with some updates from rawhide.
Any help would be very appreciated.
Bye David
PS: Please set a cc to my e-mail address, I couldn't yet subscribe using
another address then the one I send from.
Boris Kolpackov
Hi David,
Well, you said everything except in which function in ACE it happens. This
one more example why it's highly recommended to use PRF!
$ACE_ROOT/PROBLEM-REPORT-FORM
$TAO_ROOT/PROBLEM-REPORT-FORM
HTH,
-boris
--
Boris Kolpackov <mailto:bo...@ipmce.ru> <http://www.kolpackov.net>
1024D/EBB172C3 - 9879 C89B 4985 4262 216B 4006 867F 3F22 EBB1 72C3
Jody Hagins
> Hi
>
> I've got a problem with throwing exceptions in gcc-2.95.x. The source
> compiles and links without any errors and a small testprogramm throwing
> exceptions also worked flawless. But in my app using ACE+TAO I get a segfault
> whenever an exception is thrown with an IMO very strange backtrace:
>
> #0 0x40a680b1 in kill () from /lib/libc.so.6
> #1 0x40a67ed1 in raise () from /lib/libc.so.6
> #2 0x40a6942c in abort () from /lib/libc.so.6
> #3 0x401c531b in __default_terminate () from
> /usr/src/ACE_wrappers/ace/libACE.so
> Current language: auto; currently c
> #4 0x401c533c in __terminate () from /usr/src/ACE_wrappers/ace/libACE.so
> #5 0x401c5f4e in __throw () from /usr/src/ACE_wrappers/ace/libACE.so
Interesting that you are having so many problems with 3.0.3 (in a
separate email, would you please let me know what those are...).
We have used native exceptions quite successfully on 2.95/2.96 (now we
are on 3.0.3), so this is a surprise to hear. Anyway, as you probably
already know, your application is not catching the exception, so
terminate() is being called. Unfortunately, since there is no code or
anything else, all I can say is that "it works for me" :-)
David Philippi
> Well, you said everything except in which function in ACE it happens. This
> one more example why it's highly recommended to use PRF!
It doesn't happen in ACE - it happens in my own code. That's the main reason
why I was very surprised to see __throw reported to be from libACE.
I don't know what ACE does to exceptions - I know that setting an unexpected
exception handler before calling TAO's ORB_init is useless but I don't know
how ACE should change the throwing of an exception. I know only of
set_unexpected and set_terminate.
Bye David
David Philippi
> We have used native exceptions quite successfully on 2.95/2.96 (now we
> are on 3.0.3), so this is a surprise to hear. Anyway, as you probably
> already know, your application is not catching the exception, so
> terminate() is being called. Unfortunately, since there is no code or
> anything else, all I can say is that "it works for me" :-)
I've put a try .. catch around the function throwing the exception without
effect and more important - the exception get's caught using gcc-3.x.
Anyway - shouldn't a stack backtrace of an uncaught exception end in main() ?
The next line in the backtrace would have been the method throwing the
exception, the line: throw <exception object>. As far as I understand
exceptions there had to be an unwinding of the stack up to main before it can
be determined wheter the exception will be caught or not, right?
Bye David
Jody Hagins
> I've put a try .. catch around the function throwing the exception without
> effect and more important - the exception get's caught using gcc-3.x.
> Anyway - shouldn't a stack backtrace of an uncaught exception end in main() ?
> The next line in the backtrace would have been the method throwing the
> exception, the line: throw <exception object>. As far as I understand
> exceptions there had to be an unwinding of the stack up to main before it can
> be determined wheter the exception will be caught or not, right?
Can't argue with what you are seeing, but without a test case that fails
for you, I doubt anyone will be able to help much...
Craig Rodrigues
> Hi
>
> I've got a problem with throwing exceptions in gcc-2.95.x. The source
> compiles and links without any errors and a small testprogramm throwing
> exceptions also worked flawless. But in my app using ACE+TAO I get a segfault
> whenever an exception is thrown with an IMO very strange backtrace:
>
> #0 0x40a680b1 in kill () from /lib/libc.so.6
> #1 0x40a67ed1 in raise () from /lib/libc.so.6
> #2 0x40a6942c in abort () from /lib/libc.so.6
> #3 0x401c531b in __default_terminate () from
> /usr/src/ACE_wrappers/ace/libACE.so
> Current language: auto; currently c
> #4 0x401c533c in __terminate () from /usr/src/ACE_wrappers/ace/libACE.so
> #5 0x401c5f4e in __throw () from /usr/src/ACE_wrappers/ace/libACE.so
Sometimes you see these kinds of problems if you
have multiple versions of gcc on the same system.
If you compile a C++ library with one version
of gcc, and then try to link this library with another
version of gcc, you can sometimes get these problems.
This also happens if you have a libstdc++ from another
compiler in your LD_LIBRARY_PATH or linker path.
The exception handling mechanism
betweeen gcc 2.95 and gcc 3.x is not compatible,
so you need to compile and link all your C++ libraries
with the same compiler.
--
Craig Rodrigues Distributed Systems and Logistics, Office 6/304
crod...@bbn.com BBN Technologies, a Verizon company
(617) 873-4725 Cambridge, MA
David Philippi
> Can't argue with what you are seeing, but without a test case that fails
> for you, I doubt anyone will be able to help much...
Any idea how I should try to find an test case? Simple test programs work
flawless and I don't know how to approach such a problem - the app showing
the error itself is quite huge and trying to slice it down to the core of the
problem without a methodic approach doesn't look like an good idea.
Unfortunately I don't know a method to do such a type of debugging - any
hints?
BTW does per chance someone know wheter it's correct that __throw() is from
libACE.so?
Bye David
Chris Uzdavinis
> BTW does per chance someone know wheter it's correct that __throw() is from
> libACE.so?
Here is your stack trace again:
#0 0x40a680b1 in kill () from /lib/libc.so.6
#1 0x40a67ed1 in raise () from /lib/libc.so.6
#2 0x40a6942c in abort () from /lib/libc.so.6
#3 0x401c531b in __default_terminate () from
/usr/src/ACE_wrappers/ace/libACE.so
Current language: auto; currently c
#4 0x401c533c in __terminate () from /usr/src/ACE_wrappers/ace/libACE.so
#5 0x401c5f4e in __throw () from /usr/src/ACE_wrappers/ace/libACE.so
Realize that since exception handling is a runtime behavior, the
compiler generates calls into the RTL to help implement it (otherwise
it'd be emitting vast amounts of duplicate code in every function to
implement exception handling.) __throw() is a function that the
compiler-generated code called, which is linked into an application.
(Double-leading underscores indicate that the name is reserved for the
compiler/RTL implementation.)
So when an exception is thrown, the way that this actually happens is
by the runtime invoking a call to __throw. Perhaps it was throwing an
exception that violated the exception specifications, in which case
terminate is called. (That's my guess at least.)
In any case, it's almost certainly not ACE doing that. The exception
may have been caused (directly or indirectly) by a call that went into
ACE code, but the call to __throw() is internal, compiler-specific
behavior.
--
Chris
David Philippi
> Realize that since exception handling is a runtime behavior, the
> compiler generates calls into the RTL to help implement it (otherwise
> it'd be emitting vast amounts of duplicate code in every function to
> implement exception handling.) __throw() is a function that the
> compiler-generated code called, which is linked into an application.
> (Double-leading underscores indicate that the name is reserved for the
> compiler/RTL implementation.)
Yes, I know. It may be that a wrong library got linked into my code, since I
have multiple versions of gcc on my system. I'm just trying to recompile
gcc-2.95.2 to get .so files to link against. I don't know how to check which
static lib got linked in and "ldd excecutable" using the gcc-2.95.3 compiled
version doesn't show libstdc++ at all...
I wouldn't have thought this could be the case since a gcc-3.x lib doesn't
link with gcc-2.95.x in my experience, but according to the mail from Craig
Rodrigues this may be what happened.
> So when an exception is thrown, the way that this actually happens is
> by the runtime invoking a call to __throw. Perhaps it was throwing an
> exception that violated the exception specifications, in which case
> terminate is called. (That's my guess at least.)
No, that's certainly not what's happening. If it were gcc-3.x wouldn't create
a working excecutable from the source either and I'd get a call to
unexpected_exception instead which is in fact even redefined by me.
BTW this was one of the first things I checked. ;-)
> In any case, it's almost certainly not ACE doing that. The exception
> may have been caused (directly or indirectly) by a call that went into
> ACE code, but the call to __throw() is internal, compiler-specific
> behavior.
Yes, I don't know of any way to change it either. But since __throw() is
shown as a symbol from libACE by gdb I thought maybe there was some way to
change exception handling I didn't know. But I find it much easier to believe
that I've got problems with different versions of the libraries that aren't
really compatible.
Bye David
Dave Mercer
Are you executing multiple threads? I've come across instances with
gcc-2.95.x where exceptions thrown from a thread outside the actual try
block caused weird things to happen.
For instance:
try
{
this->svc(); // spawns a thread or three and does its thing before
throwing an exception
}
catch ( except& )
{
}
Chris Uzdavinis wrote:
--
+------------------------------------+--------------------------+
| Dave Mercer | ITG |
| Systems Architect | "The Future of Trading" |
| Back Office Software System (BOSS) | |
+------------------------------------+--------------------------+
| ITG Software Solutions, Inc. | Email: mer...@itgssi.com |
| 400 Corporate Pointe, Suite 600 | Phone: (213) 270-7532 |
| Culver City, California 90230 | Fax: (310) 216-0933 |
| http://www.itginc.com | |
+------------------------------------+--------------------------+
David Philippi
> Are you executing multiple threads? I've come across instances with
I'm not yet using multiple threads, I decided to spawn additional tests after
I got some tests successfully done.
> gcc-2.95.x where exceptions thrown from a thread outside the actual try
> block caused weird things to happen.
> For instance:
> try
> {
> this->svc(); // spawns a thread or three and does its thing before
> throwing an exception
> }
> catch ( except& )
> {
> }
I'm not exactly sure, but from what I remember about exception handling this
code isn't supposed to work since it's not possible to catch exceptions in
any other thread then the one in which they were raised. Correct me if I'm
wrong.
Bye David
Krishnakumar B
> Am Mittwoch, 20. Februar 2002 18:43 schrieb Chris Uzdavinis:
>
> > compiler generates calls into the RTL to help implement it (otherwise
> > it'd be emitting vast amounts of duplicate code in every function to
> > implement exception handling.) __throw() is a function that the
> > compiler-generated code called, which is linked into an application.
> > (Double-leading underscores indicate that the name is reserved for the
> > compiler/RTL implementation.)
>
> have multiple versions of gcc on my system. I'm just trying to recompile
> gcc-2.95.2 to get .so files to link against. I don't know how to check which
> static lib got linked in and "ldd excecutable" using the gcc-2.95.3 compiled
> version doesn't show libstdc++ at all...
od -c executable/object. It will show you a string like "gcc2 compiled" at
the end. If you specify the correct link path, you should be very confident
that it linked against the right library. You can always assert this using
gcc -v.
Which version of glibc are you using ? AFAIK, there is no glibc 2.2.90.
There were some bugs with gcc-2.96 with exception handling which made me
switch to gcc-3.0.x on IA64. It might well be true for ix86.
> I wouldn't have thought this could be the case since a gcc-3.x lib doesn't
> link with gcc-2.95.x in my experience, but according to the mail from Craig
> Rodrigues this may be what happened.
Ofcourse it won't link. I think that you misunderstood what Craig said.
Also make sure that you have a seperate libACE in each case (which should
be true as your executable won't link otherwise).
> > In any case, it's almost certainly not ACE doing that. The exception
> > may have been caused (directly or indirectly) by a call that went into
> > ACE code, but the call to __throw() is internal, compiler-specific
> > behavior.
>
> Yes, I don't know of any way to change it either. But since __throw() is
> shown as a symbol from libACE by gdb I thought maybe there was some way
> to change exception handling I didn't know.
You are trusting gdb too much. In my experiences it is not something that
you should attribute so much trust to.
> But I find it much easier to believe that I've got problems with
> different versions of the libraries that aren't really compatible.
Might well be.
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
strabo
" --enable-threads=posix" to make c++ exceptions thread-safe. Last time i
got bite by this ugly thing really bad. You can switch to gcc3, seems most
stock versions of gcc3 are compiled the right way.
"David Philippi" <da...@torangan.de> wrote in message
news:E16dVcx-...@mx.rootsystems.net...
David Philippi
> Which version of glibc are you using ? AFAIK, there is no glibc 2.2.90.
I was using the most actual version of glibc found on RedHat rawhide.
I'll try again (probably tomorrow) with new systems - I'm installing a
RedHat 6.2 based upon egcs which allows me to try gcc-2.95 without much
changes and a RedHat 7.2 which can be upgraded to support gcc-3.x .
I hope that my problems stem from the fact that I did to many changes to
my system during it's lifetime.
> Ofcourse it won't link. I think that you misunderstood what Craig said.
> Also make sure that you have a seperate libACE in each case (which should
> be true as your executable won't link otherwise).
I think the problem may have been dynamic linking - it's entirely
possible to let a program use different version of libstdc++ - if you
change them after your apps is compiled. I should consider static
linking for the future...
> You are trusting gdb too much. In my experiences it is not something that
> you should attribute so much trust to.
Yes, I fear you're right. Especially when using gcc-3.x gdb can't be
trusted very much.
Bye David
PS: I couldn't reply before since my Mailer uses libstdc++ and couldn't
find a compatible one after some of my experiments...
Doug Warner
I've been experiencing similarly strange exception problems with gcc-2.95.3
on sparc-sun-solaris2.6. From poking around in the gcc source code a
little, it looks like gcc emits exception handling code into each object
file on some platforms (the unwind info). It also looks like __throw is
where the RTL starts managing the exception, including looking for an
appropriate handler. The RTL may not actually try to unwind the stack
before it locates the correct handler. It might look for the handler before
unwinding the stack and check for unexpected exceptions before anything
happens to the stack. So __throw could be calling __terminate because there
was no handler.
My exception problem is different. I have a try/catch block in main() that
handles exceptions via an abstract base class. However, the ABC handler
does not get invoked at runtime. I can catch the exception via ... or by
using a more derived exception class. I can also catch the exception via
ABC if I explicitly mention the more derived class somewhere else (in a
later catch clause, or even just explicit template class instantiation).
In code, with the following hierarchy:
ExceptionBase ---| ExceptionChild< T > ---| ExceptionArg< T, D >
This fails:
main() {
...
try {
... // Something that throws ExceptionArg< MyCode, string > from
// a shared library.
}
catch( ExceptionBase &e ) {
cerr << e << endl;
return 1;
}
catch( ... ) {
cerr << "Caught an unknown exception" << endl;
return 1;
}
}
// template class ExceptionArg< MyCode, string >; // This makes it work.
Naturally, I'm suspicious that my problem is related to template
instantiation, but have yet to find a solution. A small example that seems
to include the key features works fine.
--
Doug Warner
dougwarner at micron dot com
David Philippi wrote in message ...
Nicky White
I've just completed a build of ACE/TAO on sparc-sun-solaris2.6 using
gcc-3.0.3.
I experienced some problems with exception-handling but realised that
this was caused by exception-handling being turned off for this platform
by default in the ace config files. I rebuilt with exceptions enabled
and my problems went away. Also if you're not already aware there is a
bug in the GNU libstdc++ which causes seg. faults with code that uses
the string class from libstdc++. This is specific to multiprocessor
sparc boxes.
Its fixed in libstdc++ 3.0.96. I needed to download this and replace the
version bundled with gcc-3.0.3. Hope this is of use.
Nicky