libstdc++/9756: __verbose_terminate_handler enters infinite loop

Stephen M. Webb stephenw@cryptocard.com
Fri Feb 28 21:01:00 GMT 2003


On February 28, 2003 02:11 pm, bkoz@gcc.gnu.org wrote:
>
>     Hmmm. I believe libgcc_so does have versioning support. Can somebody
> confirm this is really the problem?

I just checked, and libgcc_so does have symbol versioning (where supported).

>     Stephen can you give more detail about this bit:
>      I seems that the library libgcc_s.so.1 has been changed between 3.2
> and the latest CVS source, but does not have versioning support.

It turned out the problem was that the dynamic linker/loader was resolving 
libgcc_s.so.1 for my executable built by gcc 3.4 to the libgcc_s.so.1 built 
by gcc 3.2.

The 3.2 _Unwind_RaiseException() just fell through in __cxa_rethrow(), which 
resulted in std::terminate() being called (which in turn called 
__cxa_retrow(), ad infinitum).

When I forced the right libgcc_s.so.1 to be picked up (by setting 
LD_LIBRARY_PATH correctly *blush*), the 3.4 _Unwind_RaiseException did the 
Right Thing and actually rethrew the exception.

This leads me to believe that code produced by the 3.4 compiler is not 
backwards compatible with the runtime libraries built by the 3.2 compiler.  
Usually when this happens with a runtime library, the version number of the 
library itself gets bumped (libstdc++ does so, as does libc), allowing 
incompatible versions of the library to exist alongside each other.  This is 
evidently not the case for libgcc_s if the two versions are in fact 
incompatible.

If someone can prove that there are incompatibilities between the two versions 
of the library, the name should be changed to match, otherwise there are 
potential problems with software distribution (not to mention multiple 
versions of the toolchain existing side-by-side).

-- 
Stephen M. Webb



More information about the Gcc-bugs mailing list