Major bug -- Exception handling broken

Major bug -- Exception handling broken

[Ross Smith]

Exception handling in g++ is totally broken in the current Cygwin
release. Almost any program that uses exceptions crashes:

class Foo {};
int main() {
  try { throw Foo(); }
  catch (const Foo&) { return 0; }
}

$ g++ foo.cpp -o foo
$ ./foo
0 [main] foo 1007 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
5052 [main] foo 1007 stackdump: Dumping stack trace to foo.exe.stackdump

System is NT4+sp6a; CPU is PIII/450; Cygwin installation is straight
from the current setup.exe. If you need any more details let me know.

(I reported this last week, but nobody paid any attention.)

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
   "So that's 2 T-1s and a newsfeed ... would you like clues with that?"
                                                       -- Peter Da Silva



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Chris Faylor]

On Wed, May 31, 2000 at 07:08:41PM -0500, Larry Hall (RFK Partners, Inc) wrote:
>At 05:54 PM 5/31/00, Ross Smith wrote:
>>From: "Parker, Ron" <rdparker@butlermfg.com>
>>>My hunch about the specs file was wrong.  There are no entries related
>>>to g++.  However I did track this down to a problem with g++ using
>>>libm.a.
>>> 
>>> [snip]
>>> 
>>> gcc -v foo.cpp -o foo -lstd++ (OKAY)
>>> gcc -v foo.cpp -o foo -lstd++ -lm(BAD)
>>> gcc -v foo.cpp -o foo -lm (BAD)
>>> 
>>> So the problem seems to be with libm.a.  
>>
>>Cygwin's libm.a is a symlink to libcygwin.a.  I'll try replacing it
>>with a dummy stub library ...  <tries it> ...  nope, that made ld
>>crash.
>
>Hm.  All this rings a bell with me.  Something very old and very
>foggy....  Seems to me I recall that multiple references to libraries
>in the link stream always caused Cygwin to crash.  I believe the
>context of this the last time the issue came up was with Windows
>libraries but perhaps the issue is more generic.  Also, I recall
>discussions which stated that there isn't really a libm.a for Cygwin.
>Its all in Cygwin.  That would imply that libcygwin.a == libm.a, a
>notion that the symlink tends to support.  Given all this, its my
>impression that libm.a isn't needed, at least in the default case.
>Obviously, eliminating libm.a as a default library to link against is
>not the complete solution since some packages are going to link against
>it explicitly in their makefile and therefore still see problem (unless
>the makefile is edited!;-))  Probably we'll need to wait for Mumit to
>clarify this whole situation but eliminating the -lm seems a good
>work-around for now!;-)

You're right that adding libm.a or libc.a to the link line can screw
up constructors in g++.  I thought that this was solved in the gcc
that we're releasing.  Guess not.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Larry Hall (RFK Partners, Inc)]

At 05:54 PM 5/31/00, Ross Smith wrote:
>From: "Parker, Ron" <rdparker@butlermfg.com>
> > 
> > My hunch about the specs file was wrong.  There are no entries related to
> > g++.  However I did track this down to a problem with g++ using libm.a.
> > 
> > [snip]
> > 
> > gcc -v foo.cpp -o foo -lstd++ (OKAY)
> > gcc -v foo.cpp -o foo -lstd++ -lm(BAD)
> > gcc -v foo.cpp -o foo -lm (BAD)
> > 
> > So the problem seems to be with libm.a.  
>
>Cygwin's libm.a is a symlink to libcygwin.a. I'll try replacing it
>with a dummy stub library ... <tries it> ... nope, that made ld crash.



Hm.  All this rings a bell with me.  Something very old and very
foggy....  Seems to me I recall that multiple references to libraries in 
the link stream always caused Cygwin to crash.  I believe the context of 
this the last time the issue came up was with Windows libraries but perhaps 
the issue is more generic.  Also, I recall discussions which stated that
there isn't really a libm.a for Cygwin.  Its all in Cygwin.  That would 
imply that libcygwin.a == libm.a, a notion that the symlink tends to support.
Given all this, its my impression that libm.a isn't needed, at least in the
default case.  Obviously, eliminating libm.a as a default library to link
against is not the complete solution since some packages are going to link
against it explicitly in their makefile and therefore still see problem 
(unless the makefile is edited!;-))  Probably we'll need to wait for Mumit to
clarify this whole situation but eliminating the -lm seems a good work-around 
for now!;-)



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Ross Smith]

From: "Parker, Ron" <rdparker@butlermfg.com>
> 
> My hunch about the specs file was wrong.  There are no entries related to
> g++.  However I did track this down to a problem with g++ using libm.a.
> 
> [snip]
> 
> gcc -v foo.cpp -o foo -lstd++ (OKAY)
> gcc -v foo.cpp -o foo -lstd++ -lm(BAD)
> gcc -v foo.cpp -o foo -lm (BAD)
> 
> So the problem seems to be with libm.a.  

Cygwin's libm.a is a symlink to libcygwin.a. I'll try replacing it
with a dummy stub library ... <tries it> ... nope, that made ld crash.

> I did a little more looking around and discovered that g++ should not be
> linking against -lm.  So, I came up with the following patch that at least
> make g++ able to compile a working version of the trivial test listed above.
> It looks like a previous patch of Mumit's may have gotten dropped.
> 
> If you cannot rebuild gcc, I can email a stripped and gzip'd version of the
> fixed g++. It is only 29,995 bytes.

That would be good. Thanks for all your help!

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
   "So that's 2 T-1s and a newsfeed ... would you like clues with that?"
                                                       -- Peter Da Silva




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Major bug -- Exception handling broken

[Parker, Ron]

> Thanks, that seems to work. Are there any gotchas I need to watch out
> for when doing it this way? That is, are there any differences between
> invoking via gcc vs g++ that aren't accounted for by adding -lstdc++
> to the link step?

Not that I am aware of.  The verbose output from gcc and g++ looks identical
other than the -lstdc++ option.

RE: Major bug -- Exception handling broken

[Parker, Ron]

> > I may be wrong but I believe that Mumit is well-aware that 
> structured
> > exception handling is broken on Windows.
> > 
> 
> Yes and low priority on the TODO list.  If Ron would like to 
> take this on
> himself I'm sure that it would be a welcome fix.

Windows SEH, structured exception handling is definately broken.  I searched
the archives for references to C++ exceptions being broken and did not find
much.

If anyone can direct me to more information, I will see what I can do.  But,
I am not experienced at tearing compilers apart and putting them back
together, now cars are a different matter. :^)

RE: Major bug -- Exception handling broken

[Parker, Ron]

> > Exception handling in g++ is totally broken in the current Cygwin
> > release. Almost any program that uses exceptions crashes:
> > 
> > class Foo {};
> > int main() {
> >   try { throw Foo(); }
> >   catch (const Foo&) { return 0; }
> > }
> > 
> > $ g++ foo.cpp -o foo
> > $ ./foo
> > 0 [main] foo 1007 handle_exceptions: Exception: 
> > STATUS_ACCESS_VIOLATION
> > 5052 [main] foo 1007 stackdump: Dumping stack trace to 
> > foo.exe.stackdump
> 
> I have verified that this is a bug.  Mumit Khan, the cygwin 
> gcc guru, is out
> of the country and should be back mid-June.  In the mean time 
> I will see
> what I can find.
> 
> For the time being you may work around it by replacing g++ in 
> the command
> line with gcc.  That produces a working executable.  My best 
> guess at this
> time is that there is a problem with g++ in the specs file.  
> I will check it
> next.

My hunch about the specs file was wrong.  There are no entries related to
g++.  However I did track this down to a problem with g++ using libm.a.

When I did a:
	gcc -v foo.cpp -o foo

the following was the last line of output:
	/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -o foo.exe
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib/crt0.o
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../.. /tmp/ccT9VBnq.o -lgcc
-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

And:
	g++ -v foo.cpp -o foo

yields:
	/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -o foo.exe
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib/crt0.o
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../.. /tmp/ccjfPal7.o -lstdc++
-lm -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

The only significant differences here are the -lstdc++ and the -lm.  This
led to following tests:

gcc -v foo.cpp -o foo -lstd++	(OKAY)
gcc -v foo.cpp -o foo -lstd++	-lm(BAD)
gcc -v foo.cpp -o foo -lm (BAD)

So the problem seems to be with libm.a.  

I did a little more looking around and discovered that g++ should not be
linking against -lm.  So, I came up with the following patch that at least
make g++ able to compile a working version of the trivial test listed above.
It looks like a previous patch of Mumit's may have gotten dropped.

If you cannot rebuild gcc, I can email a stripped and gzip'd version of the
fixed g++. It is only 29,995 bytes.

Wed May 31 14:52:18 CDT 2000 Ron Parker  (rdparker@butlermfg.com)

	* i386/cygwin.h (MATH_LIBRARY): Make it null.

Re: Major bug -- Exception handling broken

[Chris Faylor]

On Thu, Jun 01, 2000 at 09:47:17AM +1200, Ross Smith wrote:
>From: "Chris Faylor" <cgf@cygnus.com>
>> 
>> I may be wrong but I believe that Mumit is well-aware that structured
>> exception handling is broken on Windows.
>
>This is C++ exception handling, not SEH. I don't know whether the
>former is implemented using the latter internally (I wouldn't have
>thought so, in GCC), but from the programmer's point of view there's
>no connection between the two.

Ok.  Remove the "structured" from my sentence above, then.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Ross Smith]

From: "Chris Faylor" <cgf@cygnus.com>
> 
> I may be wrong but I believe that Mumit is well-aware that structured
> exception handling is broken on Windows.

This is C++ exception handling, not SEH. I don't know whether the
former is implemented using the latter internally (I wouldn't have
thought so, in GCC), but from the programmer's point of view there's
no connection between the two.

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
   "So that's 2 T-1s and a newsfeed ... would you like clues with that?"
                                                       -- Peter Da Silva



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Ross Smith]

From: "Parker, Ron" <rdparker@butlermfg.com>


> > Exception handling in g++ is totally broken in the current Cygwin
> > release. Almost any program that uses exceptions crashes:
> > 
> > class Foo {};
> > int main() {
> >   try { throw Foo(); }
> >   catch (const Foo&) { return 0; }
> > }
> > 
> > $ g++ foo.cpp -o foo
> > $ ./foo
> > 0 [main] foo 1007 handle_exceptions: Exception: 
> > STATUS_ACCESS_VIOLATION
> > 5052 [main] foo 1007 stackdump: Dumping stack trace to 
> > foo.exe.stackdump
> 
> I have verified that this is a bug.  Mumit Khan, the cygwin gcc guru, is out
> of the country and should be back mid-June.  In the mean time I will see
> what I can find.
> 
> For the time being you may work around it by replacing g++ in the command
> line with gcc.  That produces a working executable.  My best guess at this
> time is that there is a problem with g++ in the specs file.  I will check it
> next.

Thanks, that seems to work. Are there any gotchas I need to watch out
for when doing it this way? That is, are there any differences between
invoking via gcc vs g++ that aren't accounted for by adding -lstdc++
to the link step?

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
   "So that's 2 T-1s and a newsfeed ... would you like clues with that?"
                                                       -- Peter Da Silva



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
> On Wed, May 31, 2000 at 01:03:05PM -0500, Parker, Ron wrote:
> >> Exception handling in g++ is totally broken in the current Cygwin
> >> release. Almost any program that uses exceptions crashes:
> >> 
> >> class Foo {};
> >> int main() {
> >>   try { throw Foo(); }
> >>   catch (const Foo&) { return 0; }
> >> }
> >> 
> >> $ g++ foo.cpp -o foo
> >> $ ./foo
> >> 0 [main] foo 1007 handle_exceptions: Exception: 
> >> STATUS_ACCESS_VIOLATION
> >> 5052 [main] foo 1007 stackdump: Dumping stack trace to 
> >> foo.exe.stackdump
> >
> >I have verified that this is a bug.  Mumit Khan, the cygwin gcc guru, is out
> >of the country and should be back mid-June.  In the mean time I will see
> >what I can find.
> >
> >For the time being you may work around it by replacing g++ in the command
> >line with gcc.  That produces a working executable.  My best guess at this
> >time is that there is a problem with g++ in the specs file.  I will check it
> >next.
> 
> I may be wrong but I believe that Mumit is well-aware that structured
> exception handling is broken on Windows.
> 

Yes and low priority on the TODO list.  If Ron would like to take this on
himself I'm sure that it would be a welcome fix.

Regards,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Major bug -- Exception handling broken

[Chris Faylor]

On Wed, May 31, 2000 at 01:03:05PM -0500, Parker, Ron wrote:
>> Exception handling in g++ is totally broken in the current Cygwin
>> release. Almost any program that uses exceptions crashes:
>> 
>> class Foo {};
>> int main() {
>>   try { throw Foo(); }
>>   catch (const Foo&) { return 0; }
>> }
>> 
>> $ g++ foo.cpp -o foo
>> $ ./foo
>> 0 [main] foo 1007 handle_exceptions: Exception: 
>> STATUS_ACCESS_VIOLATION
>> 5052 [main] foo 1007 stackdump: Dumping stack trace to 
>> foo.exe.stackdump
>
>I have verified that this is a bug.  Mumit Khan, the cygwin gcc guru, is out
>of the country and should be back mid-June.  In the mean time I will see
>what I can find.
>
>For the time being you may work around it by replacing g++ in the command
>line with gcc.  That produces a working executable.  My best guess at this
>time is that there is a problem with g++ in the specs file.  I will check it
>next.

I may be wrong but I believe that Mumit is well-aware that structured
exception handling is broken on Windows.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Major bug -- Exception handling broken

[Parker, Ron]

> Exception handling in g++ is totally broken in the current Cygwin
> release. Almost any program that uses exceptions crashes:
> 
> class Foo {};
> int main() {
>   try { throw Foo(); }
>   catch (const Foo&) { return 0; }
> }
> 
> $ g++ foo.cpp -o foo
> $ ./foo
> 0 [main] foo 1007 handle_exceptions: Exception: 
> STATUS_ACCESS_VIOLATION
> 5052 [main] foo 1007 stackdump: Dumping stack trace to 
> foo.exe.stackdump

I have verified that this is a bug.  Mumit Khan, the cygwin gcc guru, is out
of the country and should be back mid-June.  In the mean time I will see
what I can find.

For the time being you may work around it by replacing g++ in the command
line with gcc.  That produces a working executable.  My best guess at this
time is that there is a problem with g++ in the specs file.  I will check it
next.