The following complete program will enter an infinite loop when run, emitting the message terminate called after throwing an instance of 'int' int main() { throw 0; } Note that the error occurs for any exception not caught. This is a regression from 3.2. Release: unknown Environment: stephen_[914]> g++ -v Reading specs from /smw/gnu/lib/gcc-lib/i686-pc-linux-gnu/3.4/specs Configured with: /home/stephenw/gnu/gcc/configure --prefix=/smw/gnu --enable-threads --enable-languages=c++ Thread model: posix gcc version 3.4 20030219 (experimental) How-To-Repeat: echo "int main() { throw 0; }" > dc.cpp g++ -o dc dc.cpp ./dc ^C
From: Phil Edwards <phil@jaj.com> To: stephenw@cryptocard.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Wed, 19 Feb 2003 17:04:48 -0500 On Wed, Feb 19, 2003 at 04:03:05PM -0000, stephenw@cryptocard.com wrote: > > Note that the error occurs for any exception not caught. Yep. That's the point. > >How-To-Repeat: > echo "int main() { throw 0; }" > dc.cpp > g++ -o dc dc.cpp > ./dc > ^C I can't reproduce this. fenric 8% cat dc.cpp int main() { throw 0; } fenric 9% g++ -o dc dc.cpp fenric 10% ./dc terminate called after throwing an instance of 'int' Aborted (core dumped) fenric 11% Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002
From: "Stephen M. Webb" <stephenw@cryptocard.com> To: Phil Edwards <phil@jaj.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Thu, 20 Feb 2003 11:01:23 -0500 On February 19, 2003 05:04 pm, Phil Edwards wrote: > > >How-To-Repeat: > > > > echo "int main() { throw 0; }" > dc.cpp > > g++ -o dc dc.cpp > > ./dc > > ^C > > I can't reproduce this. I can't see how it's anything unique I've done, since gcc was built from unmodified CVS sources for both my 3.2 and 3.4 versions. Is it possible the problem comes from binutils (I'm using 2.13.90 20021125 for gcc 3.4) or libc (I have 2.2.5)? When I compile with gcc 3.2, I get expected behaviour: stephen_[153]> g++ -v Reading specs from /opt/gnu/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs Configured with: ../combined/configure --enable-languages=c++ --prefix=/opt/gnu --enable-threads Thread model: posix gcc version 3.2 20020326 (experimental) stephen_[154]> g++ -o dc dc.cpp stephen_[155]> ./dc Abort stephen_[156]> When I compile with yesterday's main trunk CVS (actually, it goes back a ways before yesterday), I get the following unexpected behaviour. stephen_[1033]> g++ -v Reading specs from /smw/gnu/lib/gcc-lib/i686-pc-linux-gnu/3.4/specs Configured with: /home/stephenw/gnu/gcc/configure --prefix=/smw/gnu --enable-threads --enable-languages=c++ Thread model: posix gcc version 3.4 20030219 (experimental) stephen_[1034]> g++ -o dc dc.cpp stephen_[1035]> ./dc terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after thro^C stephen_[1036]> A gdb session reveals the following stack trace. .... terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' terminate called after throwing an instance of 'int' Program received signal SIGINT, Interrupt. 0x401c1184 in __libc_write () at __libc_write:-1 -1 __libc_write: No such file or directory. in __libc_write (gdb) bt #0 0x401c1184 in __libc_write () at __libc_write:-1 #1 0x400cfd18 in __JCR_LIST__ () from /smw/gnu/lib/libstdc++.so.6 #2 0x400acbf5 in __cxxabiv1::__terminate(void (*)()) ( handler=0x400aef50 <__gnu_cxx::__verbose_terminate_handler()>) at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:43 #3 0x400acc32 in std::terminate() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:53 #4 0x400ace0d in __cxa_rethrow () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:104 #5 0x400af034 in __gnu_cxx::__verbose_terminate_handler() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/vterminate.cc:81 #6 0x400acbf5 in __cxxabiv1::__terminate(void (*)()) ( handler=0x400aef50 <__gnu_cxx::__verbose_terminate_handler()>) at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:43 #7 0x400acc32 in std::terminate() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:53 .... #10212 0x400ace0d in __cxa_rethrow () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:104 #10213 0x400af034 in __gnu_cxx::__verbose_terminate_handler() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/vterminate.cc:81 #10214 0x400acbf5 in __cxxabiv1::__terminate(void (*)()) ( handler=0x400aef50 <__gnu_cxx::__verbose_terminate_handler()>) at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:43 #10215 0x400acc32 in std::terminate() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:53 #10216 0x400ace0d in __cxa_rethrow () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:104 #10217 0x400af034 in __gnu_cxx::__verbose_terminate_handler() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/vterminate.cc:81 #10218 0x400acbf5 in __cxxabiv1::__terminate(void (*)()) ( handler=0x400aef50 <__gnu_cxx::__verbose_terminate_handler()>) at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:43 #10219 0x400acc32 in std::terminate() () at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:53 #10220 0x400acdc2 in __cxa_throw (obj=0x400b7d59, tinfo=0x2d, dest=0x2d) at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:80 #10221 0x080484fe in main () #10222 0x40119472 in __libc_start_main (main=0x80484c4 <main>, argc=1, ubp_av=0x804a660, init=0x804839c <_init>, fini=0x40013d8c <_dl_debug_mask>, rtld_fini=0x400b7fc0 <typeinfo name for __cxxabiv1::__fundamental_type_info+128>, stack_end=0x30) at ../sysdeps/generic/libc-start.c:129 (gdb) -- Stephen M. Webb
From: Phil Edwards <phil@jaj.com> To: "Stephen M. Webb" <stephenw@cryptocard.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Thu, 20 Feb 2003 11:25:08 -0500 On Thu, Feb 20, 2003 at 11:01:23AM -0500, Stephen M. Webb wrote: > On February 19, 2003 05:04 pm, Phil Edwards wrote: > > > >How-To-Repeat: > > > > > > echo "int main() { throw 0; }" > dc.cpp > > > g++ -o dc dc.cpp > > > ./dc > > > ^C > > > > I can't reproduce this. > > I can't see how it's anything unique I've done, since gcc was built from > unmodified CVS sources for both my 3.2 and 3.4 versions. Is it possible the > problem comes from binutils (I'm using 2.13.90 20021125 for gcc 3.4) or libc > (I have 2.2.5)? Possibly, yes. > When I compile with gcc 3.2, I get expected behaviour: The sources have changed since then; in 3.2 we simply died. Now the verbose termination routine is on by default. > .... > #10212 0x400ace0d in __cxa_rethrow () at > /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:104 > #10213 0x400af034 in __gnu_cxx::__verbose_terminate_handler() () > at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/vterminate.cc:81 > #10214 0x400acbf5 in __cxxabiv1::__terminate(void (*)()) ( > handler=0x400aef50 <__gnu_cxx::__verbose_terminate_handler()>) > at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:43 > #10215 0x400acc32 in std::terminate() () at > /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:53 > #10216 0x400ace0d in __cxa_rethrow () at > /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:104 > #10217 0x400af034 in __gnu_cxx::__verbose_terminate_handler() () > at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/vterminate.cc:81 > #10218 0x400acbf5 in __cxxabiv1::__terminate(void (*)()) ( > handler=0x400aef50 <__gnu_cxx::__verbose_terminate_handler()>) > at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:43 > #10219 0x400acc32 in std::terminate() () at > /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:53 > #10220 0x400acdc2 in __cxa_throw (obj=0x400b7d59, tinfo=0x2d, dest=0x2d) > at /home/stephenw/gnu/gcc/libstdc++-v3/libsupc++/eh_throw.cc:80 > #10221 0x080484fe in main () Hmmmm. The verbose terminate handler re-throws the exception in order to try and give the user more help: // If the exception is derived from std::exception, we can give more // information. try { __throw_exception_again; } #ifdef __EXCEPTIONS catch (exception &exc) { char const *w = exc.what(); writestr(" what(): "); writestr(w); writestr("\n"); } #endif catch (...) { } The rethrow never... eh, I don't know how to express this clearly. The rethrow never rethrows; it never leaves the try block. Instead, the support routine __cxa_rethrow calles std::terminate, and there's the infinite loop. I have no idea why; the core dump I get (and the rest of us got during testing) shows this: #0 0x40124a51 in kill () from /lib/libc.so.6 #1 0x40124872 in raise () from /lib/libc.so.6 #2 0x40125986 in abort () from /lib/libc.so.6 #3 0x400a1fcb in __gnu_cxx::__verbose_terminate_handler() () at /home/pme/src/unified/libstdc++-v3/libsupc++/vterminate.cc:96 The same thing up until the rethrow; it's supposed to finish the rethrow, hit the "catch (...) { }" line, and then abort() a few lines later (line 96). Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002
From: "Stephen M. Webb" <stephenw@cryptocard.com> To: Phil Edwards <phil@jaj.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Thu, 20 Feb 2003 11:59:55 -0500 On February 20, 2003 11:25 am, Phil Edwards wrote: > > The rethrow never rethrows; it never leaves the try block. Instead, > the support routine __cxa_rethrow calles std::terminate, and there's the > infinite loop. > > I have no idea why; the core dump I get (and the rest of us got during > testing) shows this: > > #0 0x40124a51 in kill () from /lib/libc.so.6 > #1 0x40124872 in raise () from /lib/libc.so.6 > #2 0x40125986 in abort () from /lib/libc.so.6 > #3 0x400a1fcb in __gnu_cxx::__verbose_terminate_handler() () at > /home/pme/src/unified/libstdc++-v3/libsupc++/vterminate.cc:96 Did you build with --enable-threads? -- Stephen M. Webb
From: Phil Edwards <phil@jaj.com> To: "Stephen M. Webb" <stephenw@cryptocard.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Thu, 20 Feb 2003 12:03:48 -0500 On Thu, Feb 20, 2003 at 11:59:55AM -0500, Stephen M. Webb wrote: > On February 20, 2003 11:25 am, Phil Edwards wrote: > > > > The rethrow never rethrows; it never leaves the try block. Instead, > > the support routine __cxa_rethrow calles std::terminate, and there's the > > infinite loop. > > > > I have no idea why; the core dump I get (and the rest of us got during > > testing) shows this: > > > > #0 0x40124a51 in kill () from /lib/libc.so.6 > > #1 0x40124872 in raise () from /lib/libc.so.6 > > #2 0x40125986 in abort () from /lib/libc.so.6 > > #3 0x400a1fcb in __gnu_cxx::__verbose_terminate_handler() () at > > /home/pme/src/unified/libstdc++-v3/libsupc++/vterminate.cc:96 > > Did you build with --enable-threads? Always. Hmmm... you're on Linux. Can you try building with --enable-__cxa_atexit and see what happens? I've put out a call for help; I'm not familiar with the guts of the _Unwind* framework. Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002
From: "Stephen M. Webb" <stephenw@cryptocard.com> To: Phil Edwards <phil@jaj.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Thu, 20 Feb 2003 14:32:01 -0500 On February 20, 2003 12:03 pm, Phil Edwards wrote: > > I've put out a call for help; I'm not familiar with the guts of the > _Unwind* framework. I found my problem. 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. Because of the twisty maze of little passages used to resolve dynamic linker dependencies my programs built with the 3.4 compiler were picking up the incompatible 3.2 libgcc_s.so.1. I guess 9756 should be closed. Someone might consider bumping the version number on that library, though, if version incompatibilities are going to cause runtime errors. -- Stephen M. Webb
From: "Stephen M. Webb" <stephenw@cryptocard.com> To: bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, pme@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Fri, 28 Feb 2003 16:01:34 -0500 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
Responsible-Changed-From-To: unassigned->pme Responsible-Changed-Why: Phil, I assigned this to you for the time being, okay?
State-Changed-From-To: open->analyzed State-Changed-Why: Hmmm. I believe libgcc_so does have versioning support. Can somebody confirm this is really the problem? 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. That's bad news, if true. Perhaps something like 'check-abi' is needed for libgcc_so? What's the change? Is it something as simple as just adding a new exported symbol? -benjamin
This has moved out of the realm of libstdc++ and into libgcc_s, which I'm not really qualified to speak on. (I think it has versioning, but *shrug*.) So I'm changing the description and component.
libgcc_s.so does have symbol version see libgcc-std.ver and has since: 2000-10-05 Richard Henderson * Makefile.in (NM_FOR_TARGET): New. (libgcc.mk): Pass SHLIB_MKMAP, SHLIB_MAPFILES. (libgcc.a, stmp-multilib): Pass NM_FOR_TARGET. * mklibgcc.in: If SHLIB_MKMAP, build libgcc.map. Depend the shared library build on that and EXTRA_MULTILIB_PARTS. * mkmap-flat.awk: New file. * mkmap-symver.awk: New file. * libgcc-std.ver: New file. * config/libgcc-glibc.ver: New file. * config/ia64/libgcc-ia64.ver: New file. * config/t-linux (SHLIB_MKMAP, SHLIB_MAPFILES): New. (SHLIB_LINK): Add --version-script. * config/ia64/t-ia64 (SHLIB_MAPFILES): Add libgcc-ia64.ver. * config/mips/t-iris6 (SHLIB_MKMAP, SHLIB_MAPFILES): New. * config/sparc/t-sol2 (SHLIB_MKMAP, SHLIB_MAPFILES): New. (SHLIB_LINK): Add -M.
Not our fault that your programs are picking up the wrong libgcc_s.so.