Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Phil Edwards]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Stephen M. Webb]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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
 

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[bkoz]

Synopsis: __verbose_terminate_handler enters infinite loop

Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: bkoz
Responsible-Changed-When: Fri Feb 28 19:11:24 2003
Responsible-Changed-Why:
    Phil, I assigned this to you for the time being, okay?
State-Changed-From-To: open->analyzed
State-Changed-By: bkoz
State-Changed-When: Fri Feb 28 19:11:24 2003
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

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9756

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Stephen M. Webb]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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
 

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Stephen M. Webb]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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
 

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Phil Edwards]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Stephen M. Webb]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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
 

Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

[Phil Edwards]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

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

libstdc++/9756: __verbose_terminate_handler enters infinite loop

[stephenw]

>Number:         9756
>Category:       libstdc++
>Synopsis:       __verbose_terminate_handler enters infinite loop
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 19 16:06:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     stephenw@cryptocard.com
>Release:        unknown-1.0
>Organization:
>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)
>Description:
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.
>How-To-Repeat:
echo "int main() { throw 0; }" > dc.cpp
g++ -o dc dc.cpp
./dc
^C
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: