gcc 4.3.2 libgcc_s.so exception handling broken?

[Ryan Stone]

I saw a very similar thing happen when we moved to gcc 4.3 on a 6.1 system.
The problem ended up being that we were linking everything, including shared
objects, against a static libgcc.  This meant that when a C++ program loaded
a C++ shared object, there'd be two copies of the exception handling code in
the process.  What happened was the the executable registered all its
exception handlers with the copy in the excecutable, and then loaded the
shared object.  When it raised an exception, it called the exception
handling code in the shared object, which didn't know anything about the
exception handlers in the executable, so it couldn't find them, so it called
terminate().  The solution was to link everything against a dynamic libgcc,
so there'd only be one copy of the exception handling code.

Your problem may be similar.  I doubt that you're statically linking libgcc
in, but if you are, that's you're problem.  My guess is that either your
executable, or another shared library that your exectuable uses, is linking
against a different libgcc_s.so, which would cause the same problem(multiple
copies of the exception handling code).  ldd should be able to tell you if
this is the case.

Ryan Stone