public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-20 16:26 Phil Edwards
0 siblings, 0 replies; 9+ messages in thread
From: Phil Edwards @ 2003-02-20 16:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-28 21:06 Stephen M. Webb
0 siblings, 0 replies; 9+ messages in thread
From: Stephen M. Webb @ 2003-02-28 21:06 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-28 19:11 bkoz
0 siblings, 0 replies; 9+ messages in thread
From: bkoz @ 2003-02-28 19:11 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, pme, stephenw
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-20 19:36 Stephen M. Webb
0 siblings, 0 replies; 9+ messages in thread
From: Stephen M. Webb @ 2003-02-20 19:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-20 17:06 Phil Edwards
0 siblings, 0 replies; 9+ messages in thread
From: Phil Edwards @ 2003-02-20 17:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-20 17:06 Stephen M. Webb
0 siblings, 0 replies; 9+ messages in thread
From: Stephen M. Webb @ 2003-02-20 17:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-20 16:06 Stephen M. Webb
0 siblings, 0 replies; 9+ messages in thread
From: Stephen M. Webb @ 2003-02-20 16:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-19 22:06 Phil Edwards
0 siblings, 0 replies; 9+ messages in thread
From: Phil Edwards @ 2003-02-19 22:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* libstdc++/9756: __verbose_terminate_handler enters infinite loop
@ 2003-02-19 16:06 stephenw
0 siblings, 0 replies; 9+ messages in thread
From: stephenw @ 2003-02-19 16:06 UTC (permalink / raw)
To: gcc-gnats
>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:
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-02-28 21:06 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-20 16:26 libstdc++/9756: __verbose_terminate_handler enters infinite loop Phil Edwards
-- strict thread matches above, loose matches on Subject: below --
2003-02-28 21:06 Stephen M. Webb
2003-02-28 19:11 bkoz
2003-02-20 19:36 Stephen M. Webb
2003-02-20 17:06 Phil Edwards
2003-02-20 17:06 Stephen M. Webb
2003-02-20 16:06 Stephen M. Webb
2003-02-19 22:06 Phil Edwards
2003-02-19 16:06 stephenw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).