RE: problem with dynamic_cast

RE: problem with dynamic_cast

[Fleischer, Karsten (K.)]

How about including the stub libraries in the distribution, rather than the
symlinks?


> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: Freitag, 8. September 2000 15:11
> To: Larry Hall (RFK Partners, Inc); Fleischer, Karsten (K.);
> 'kris.thielemans@ic.ac.uk'
> Cc: Cygwin (E-mail)
> Subject: RE: problem with dynamic_cast
> 
> 
> --- "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com> wrote:
> > Quite true.  -lm and -lc are not necessary with Cygwin.  
> The support for 
> > them are in the Cygwin DLL/lib which is linked in 
> automatically.  Linking
> > with it twice (or more) guarantees a crash.  The simple 
> answer is, don't
> > us -lm or -lc with Cygwin.
> > 
> 
> My suggestion to this problem:
> 
> Replace the symbolic links with stub libraries.  I've 
> attached them for your
> convenience.  With the stub libraries it won't matter if you 
> forget to not use
> -lm or -lc 'cause things will work correctly.
> 
> Cheers,
> 
> =====
> --- < http://earniesystems.safeshopper.com > ---
>    Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
>             __Cygwin: POSIX on Windows__
> Cygwin Newbies: < http://gw32.freeyellow.com/ >
>            __Minimalist GNU for Windows__
>   Mingw32 List: < http://www.egroups.com/group/mingw32/ >
>     Mingw Home: < http://www.mingw.org/ >
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> 

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

Re: problem with dynamic_cast

[Chris Faylor]

On Fri, Sep 08, 2000 at 10:18:42AM -0400, Fleischer, Karsten (K.) wrote:
>How about including the stub libraries in the distribution, rather than the
>symlinks?

The reason for the symlinks is that some packages search libc.a and libm.a
for symbols.

If linking libc.a twice causes problems, then it *is* a bug in either gcc or
ld.

Mumit had vowed once to fix this problem but then he disappeared...

cgf

>> -----Original Message-----
>> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
>> Sent: Freitag, 8. September 2000 15:11
>> To: Larry Hall (RFK Partners, Inc); Fleischer, Karsten (K.);
>> 'kris.thielemans@ic.ac.uk'
>> Cc: Cygwin (E-mail)
>> Subject: RE: problem with dynamic_cast
>> 
>> 
>> --- "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com> wrote:
>> > Quite true.  -lm and -lc are not necessary with Cygwin.  
>> The support for 
>> > them are in the Cygwin DLL/lib which is linked in 
>> automatically.  Linking
>> > with it twice (or more) guarantees a crash.  The simple 
>> answer is, don't
>> > us -lm or -lc with Cygwin.
>> > 
>> 
>> My suggestion to this problem:
>> 
>> Replace the symbolic links with stub libraries.  I've 
>> attached them for your
>> convenience.  With the stub libraries it won't matter if you 
>> forget to not use
>> -lm or -lc 'cause things will work correctly.
>> 
>> Cheers,
>> 
>> =====
>> --- < http://earniesystems.safeshopper.com > ---
>>    Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
>>             __Cygwin: POSIX on Windows__
>> Cygwin Newbies: < http://gw32.freeyellow.com/ >
>>            __Minimalist GNU for Windows__
>>   Mingw32 List: < http://www.egroups.com/group/mingw32/ >
>>     Mingw Home: < http://www.mingw.org/ >
>> 
>> __________________________________________________
>> Do You Yahoo!?
>> Yahoo! Mail - Free email you can access from anywhere!
>> http://mail.yahoo.com/
>> 
>
>--
>Want to unsubscribe from this list?
>Send a message to cygwin-unsubscribe@sourceware.cygnus.com

-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourceware.cygnus.com/         http://www.redhat.com/

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

Re: problem with dynamic_cast

[Chris Faylor]

On Fri, Sep 08, 2000 at 12:46:31PM -0400, Chris Faylor wrote:
>On Fri, Sep 08, 2000 at 10:18:42AM -0400, Fleischer, Karsten (K.) wrote:
>>How about including the stub libraries in the distribution, rather than the
>>symlinks?
>
>The reason for the symlinks is that some packages search libc.a and libm.a
>for symbols.
>
>If linking libc.a twice causes problems, then it *is* a bug in either gcc or
>ld.
>
>Mumit had vowed once to fix this problem but then he disappeared...

Ok, I looked into this.  It is a linker problem.  Specifying -lm or -lc on
the command line causes ld to put symbols into the import section in improperly
sorted order.

This confuses the Windows "dynamic loader" (and I use the term loosely) so that
certain function calls (namely strcmp and strlen) are not resolved.  So when
a function in libgcc needs to call strcmp it ends up jumping into unallocated
memory, causing a SIGSEGV.

That's the analysis.  I have no idea how to fix this, but I've sent some details
to DJ in the hopes that he'll be able to do something about this.

cgf

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

Re: problem with dynamic_cast

[David Starks-Browning]

On Friday 8 Sep 00, Chris Faylor writes:
> On Fri, Sep 08, 2000 at 12:46:31PM -0400, Chris Faylor wrote:
> >On Fri, Sep 08, 2000 at 10:18:42AM -0400, Fleischer, Karsten (K.) wrote:
> >>How about including the stub libraries in the distribution, rather than the
> >>symlinks?
> >
> >The reason for the symlinks is that some packages search libc.a and libm.a
> >for symbols.
> >
> >If linking libc.a twice causes problems, then it *is* a bug in either gcc or
> >ld.
> >
> >Mumit had vowed once to fix this problem but then he disappeared...
> 
> Ok, I looked into this.  It is a linker problem.  Specifying -lm or -lc on
> the command line causes ld to put symbols into the import section in improperly
> sorted order.
> 
> This confuses the Windows "dynamic loader" (and I use the term loosely) so that
> certain function calls (namely strcmp and strlen) are not resolved.  So when
> a function in libgcc needs to call strcmp it ends up jumping into unallocated
> memory, causing a SIGSEGV.
> 
> That's the analysis.  I have no idea how to fix this, but I've sent some details
> to DJ in the hopes that he'll be able to do something about this.

Would it be helpful if I put this in the FAQ?
(Under "Known Problems in the Current Net Release".)

Cheers,
David


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

Re: problem with dynamic_cast

[Chris Faylor]

On Tue, Sep 12, 2000 at 02:55:00PM +0100, David Starks-Browning wrote:
>On Friday 8 Sep 00, Chris Faylor writes:
>> On Fri, Sep 08, 2000 at 12:46:31PM -0400, Chris Faylor wrote:
>> >On Fri, Sep 08, 2000 at 10:18:42AM -0400, Fleischer, Karsten (K.) wrote:
>> >>How about including the stub libraries in the distribution, rather than the
>> >>symlinks?
>> >
>> >The reason for the symlinks is that some packages search libc.a and libm.a
>> >for symbols.
>> >
>> >If linking libc.a twice causes problems, then it *is* a bug in either gcc or
>> >ld.
>> >
>> >Mumit had vowed once to fix this problem but then he disappeared...
>> 
>> Ok, I looked into this.  It is a linker problem.  Specifying -lm or -lc on
>> the command line causes ld to put symbols into the import section in improperly
>> sorted order.
>> 
>> This confuses the Windows "dynamic loader" (and I use the term loosely) so that
>> certain function calls (namely strcmp and strlen) are not resolved.  So when
>> a function in libgcc needs to call strcmp it ends up jumping into unallocated
>> memory, causing a SIGSEGV.
>> 
>> That's the analysis.  I have no idea how to fix this, but I've sent some details
>> to DJ in the hopes that he'll be able to do something about this.
>
>Would it be helpful if I put this in the FAQ?
>(Under "Known Problems in the Current Net Release".)

Yes.  "We" (this is the royal we) are working on the problem in the meantime.

cgf

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

Re: problem with dynamic_cast

[Chris Faylor]

On Fri, Sep 08, 2000 at 11:00:49PM -0400, Chris Faylor wrote:
>On Fri, Sep 08, 2000 at 12:46:31PM -0400, Chris Faylor wrote:
>>On Fri, Sep 08, 2000 at 10:18:42AM -0400, Fleischer, Karsten (K.) wrote:
>>>How about including the stub libraries in the distribution, rather than the
>>>symlinks?
>>
>>The reason for the symlinks is that some packages search libc.a and libm.a
>>for symbols.
>>
>>If linking libc.a twice causes problems, then it *is* a bug in either gcc or
>>ld.
>>
>>Mumit had vowed once to fix this problem but then he disappeared...
>
>Ok, I looked into this.  It is a linker problem.  Specifying -lm or -lc on
>the command line causes ld to put symbols into the import section in improperly
>sorted order.
>
>This confuses the Windows "dynamic loader" (and I use the term loosely) so that
>certain function calls (namely strcmp and strlen) are not resolved.  So when
>a function in libgcc needs to call strcmp it ends up jumping into unallocated
>memory, causing a SIGSEGV.
>
>That's the analysis.  I have no idea how to fix this, but I've sent some details
>to DJ in the hopes that he'll be able to do something about this.

FYI, DJ has checked in fixes for this into the latest binutils.

I'll probably provide an experimental binutils version in the next couple of
days.

cgf

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

RE: problem with dynamic_cast

[Kris Thielemans]

Hi Earnie,

yes, the empty libraries did the trick. Great, thanks !

Hi Larry,

sorry to have reacted so defensively. Just a case of someone having lost a
lot of time. Your suggestion was appreciated. (Of course, my example was so
simple because we spent a lot of time boiling down a problem with a several
megabyte library down to 1 file).


All the best,

Kris


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

RE: problem with dynamic_cast

[Bernard Dautrevaux]

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> Sent: Friday, September 08, 2000 3:53 PM
> To: Fleischer, Karsten (K.); 'kris.thielemans@ic.ac.uk'
> Cc: Cygwin (E-mail)
> Subject: RE: problem with dynamic_cast
> 
> 
> Quite true.  -lm and -lc are not necessary with Cygwin.  The 
> support for 
> them are in the Cygwin DLL/lib which is linked in 
> automatically.  Linking
> with it twice (or more) guarantees a crash.  The simple 
> answer is, don't
> us -lm or -lc with Cygwin.
> 

Obviously if I create a program to work on cygwin, I'll be careful not to
add "-lm" to my link commands; however I quite often just port UNIX programs
to cygwin and then I may forget to remove "-lm" from the makefiles (or
oversee them). 

Just saying "dont use -lm" is a bit harsh on the developper; at the least we
should avoid delivering libm.a, so we will get a clear message "libm.a" not
found, that could be looked up in the FAQ quite simply. Now we just link
correctly but then crash misteriously ;-(

I think I remember someone already suggest a simple solution to the fact the
"-lm" crash under cygwin but it seems it was never implemented :-( :

Instead of having libm.a (and libc.a BTW) be a symbolic link to libcygwin.a,
just create one (two) empty libraries named "libm.a" and "libc.a"; linking
several times to these libraries would then essentially do nothing, which is
what we expect, instead of creating a "crashing" executable :-)

Maybe I'm just tood tosee the obvious problem this causes that will prevent
cygwin to be useful :-)

I know I should provide a patch, but I just don't know where to look :-)

Just my 2 cents,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

RE: problem with dynamic_cast

[Larry Hall (RFK Partners, Inc)]

At 10:01 AM 9/8/2000, Kris Thielemans wrote:

> > Quite true.  -lm and -lc are not necessary with Cygwin.  The support for
> > them are in the Cygwin DLL/lib which is linked in automatically.  Linking
> > with it twice (or more) guarantees a crash.  The simple answer is, don't
> > us -lm or -lc with Cygwin.
> >
>
>Dear Larry,
>
>I don't think that's a viable solution. One of the important benefits  of
>cygwin is to be able to part programs from Unix to Windows. Now you might
>not be using numeric C++ packages, but lots of other people do. We do not
>want to go and change all Makefiles, do we ?
>
>Also, providing the patch would prevent other people having to waste 4 days
>with tracking the bug. Ok, somebody will have to waste time to install the
>patch of course, but I think in the end it's worth it, especially as I won't
>be the one installing the patch :-).
>
>Kris


Hi Kris,

Right now, there isn't a "patch".  That doesn't mean there won't be.  I'm
simply pointing out a work-around to your current problem in the meantime.
Your original example was so simple that this seemed like a viable one.  
Dealing with it in makefiles that already exist may be more of an issue.
Another option may be to simply create an empty libm.a library in place of the symlink (although I seem to recall some ancient discussion on this topic 
that swayed people away for this option.)  YMMV.

Of course, if you're interested in investigating the issue and providing
an appropriate patch, I'm sure it will be thoughtfully considered!:-)


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


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

RE: problem with dynamic_cast

[Earnie Boyd]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

--- "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com> wrote:
> Quite true.  -lm and -lc are not necessary with Cygwin.  The support for 
> them are in the Cygwin DLL/lib which is linked in automatically.  Linking
> with it twice (or more) guarantees a crash.  The simple answer is, don't
> us -lm or -lc with Cygwin.
> 

My suggestion to this problem:

Replace the symbolic links with stub libraries.  I've attached them for your
convenience.  With the stub libraries it won't matter if you forget to not use
-lm or -lc 'cause things will work correctly.

Cheers,

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

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
libc.a
libm.a
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


[-- Attachment #2: libc.a --]
[-- Type: application/x-archive, Size: 490 bytes --]

[-- Attachment #3: libm.a --]
[-- Type: application/x-archive, Size: 490 bytes --]

RE: problem with dynamic_cast

[Kris Thielemans]

> Quite true.  -lm and -lc are not necessary with Cygwin.  The support for
> them are in the Cygwin DLL/lib which is linked in automatically.  Linking
> with it twice (or more) guarantees a crash.  The simple answer is, don't
> us -lm or -lc with Cygwin.
>

Dear Larry,

I don't think that's a viable solution. One of the important benefits  of
cygwin is to be able to part programs from Unix to Windows. Now you might
not be using numeric C++ packages, but lots of other people do. We do not
want to go and change all Makefiles, do we ?

Also, providing the patch would prevent other people having to waste 4 days
with tracking the bug. Ok, somebody will have to waste time to install the
patch of course, but I think in the end it's worth it, especially as I won't
be the one installing the patch :-).

Kris


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

RE: problem with dynamic_cast

[Larry Hall (RFK Partners, Inc)]

Quite true.  -lm and -lc are not necessary with Cygwin.  The support for 
them are in the Cygwin DLL/lib which is linked in automatically.  Linking
with it twice (or more) guarantees a crash.  The simple answer is, don't
us -lm or -lc with Cygwin.

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



At 07:58 AM 9/8/2000, Fleischer, Karsten (K.) wrote:
>Hi Kris,
>
>I didn't look at your example, but I think you shouldn't use -lm (and -lc).
>libm.a/libc.a are symlinked to libcygwin.a and this is linked against every
>program by default. I ran into troubles and stackdumps too, when linking
>with -lm. I think there's more about this problem in the archives.
>
>Karsten
>
> > -----Original Message-----
> > From: Kris Thielemans [ mailto:kris.thielemans@ic.ac.uk ]
> > Sent: Freitag, 8. September 2000 12:46
> > To: Gnuwin
> > Cc: gcc-bugs@gcc.gnu.org
> > Subject: RE: problem with dynamic_cast
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Chris Faylor [ mailto:cgf@cygnus.com ]
> > > Sent: 07 September 2000 17:01
> > > To: Gnuwin
> > > Cc: kris.thielemans@csc.mrc.ac.uk
> > > Subject: Re: problem with dynamic_cast
> > >
> > >
> > > This is a c++ problem.  You should probably report this to a c++
> > > mailing list.
> > 
> > I doubt it really, but I send this to a C++ mailing list 
> > anyway. I've been
> > able to boil it down to something really simple. If the latest gcc
> > distribution is that broken, we're all in trouble.
> > 
> > Summarising: in cygwin 1.1.4, or the gcc (or ld) distributed 
> > with it (I've
> > installed 1.1.4 yesterday), there is a conflict with using 
> > RTTI and using
> > the math library.
> > 
> > 
> > Attached is a VERY simple C++ program that uses RTTI, but 
> > nothing else.
> > Compile it with
> > 
> > g++ dynamic_cast.cxx -lm
> > 
> > When you run it, it crashes in the dynamic_cast statement. On 
> > the other
> > hand, compile it with
> > 
> > g++ dynamic_cast.cxx
> > 
> > -> it runs fine (i.e. does essentially nothing).
> > 
> > 
> > 
> > 
> > More details:
> > 
> > I'm running NT 4.0 sp5 and cygwin 1.1.4.
> > 
> > screendump of running g++ -v:
> > 
> > $ g++ dynamic_cast.cxx -lm -v
> > Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/specs
> > gcc version 2.95.2 19991024 (release-2)
> > 
> > /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe -lang-c++ -v 
> > -D__GNUC__=2 -D_
> > _GN
> > UG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_X86=1 
> > -D__STDC__=1 -D__st
> > dcal
> > l=__attribute__((__stdcall__)) 
> > -D__cdecl=__attribute__((__cdecl__)) -D__decl
> > spec
> > (x)=__attribute__((x)) -D__i386__ -D_X86=1 -D__STDC__=1 
> > -D__stdcall=__attrib
> > ute_
> > _((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) 
> > -D__declspec(x)=__attr
> > ibut
> > e__((x)) -D__i386 -Asystem(winnt) -Acpu(i386) -Amachine(i386) 
> > -D__EXCEPTIONS
> >  -re
> > map -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ 
> > -Di686 -Dpentiump
> > ro -
> > D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ 
> > -D__CYGWIN32__ -D__CYGWIN
> > __ -
> > Dunix -D_WIN32 -DWINNT dynamic_cast.cxx /cygdrive/c/TMP/ccpF3zVU.ii
> > GNU CPP version 2.95.2 19991024 (release-2) (80386, BSD syntax)
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/include
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include
> >  /usr/include
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/include
> >  /usr/include
> > End of search list.
> > The following default directories have been omitted from the 
> > search path:
> >  /usr/include/g++
> >  /usr/X11R6.4/include
> >  /usr/local/include
> > End of omitted list.
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cc1plus.exe
> > /cygdrive/c/TMP/ccpF3zVU.ii
> > -quiet -dumpbase dynamic_cast.cc -version -o 
> > /cygdrive/c/TMP/ccKbIuaN.s
> > GNU C++ version 2.95.2 19991024 (release-2) (i686-pc-cygwin) 
> > compiled by GNU
> > C v
> > ersion 2.95.2 19991024 (release-2).
> >  as -o /cygdrive/c/TMP/cc7g2nmV.o /cygdrive/c/TMP/ccKbIuaN.s
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -Bdynamic
> > /usr/lib/crt0.o -
> > L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
> > /cygdrive/c/TMP/cc7g2nmV.o -lstdc++ -lm
> > -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
> > 
> > ld.dump attached is a screendump from running ld --verbose 
> > explicitly, after
> > removing as much libraries and options I could, while still 
> > reproducing the
> > crash.
> > 
> > 
> > gdb.dump is a screendump from running gdb on the file
> > 
>
>--
>Want to unsubscribe from this list?
>Send a message to cygwin-unsubscribe@sourceware.cygnus.com


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

RE: problem with dynamic_cast

[Fleischer, Karsten (K.)]

> -----Original Message-----
> From: Kris Thielemans [ mailto:kris.thielemans@ic.ac.uk ]
> Sent: Freitag, 8. September 2000 13:54
> To: Fleischer, Karsten (K.)
> Cc: Cygwin (E-mail)
> Subject: RE: problem with dynamic_cast
> 
> 
> 
> Dear Karsten,
> 
> yes, that's seems to be it. Many thanks !
> 
> I also found the relevant emails in the archive now (I was 
> looking for RTTI
> and dynamic_cast, but the relevant mails didn't mention those).
> 
> For those interested, you could start with:
> http://www.delorie.com/archives/thread.cgi?msg=cygwin/2000/05/
> 31/19:11:09
> 
> 
> It would be wonderful if somebody could provide me with a patched gcc,
> and/or update the distribution.


Yes, indeed! A patch would be nice. Even if you keep the simple rule "Don't
link with -lm/-lc" in mind, you sometimes forget about it :-)
Scanning old makefiles for these isn't fun at all either.


> 
> Thanks again,
> 
> Kris
> 
> 
> > Hi Kris,
> >
> > I didn't look at your example, but I think you shouldn't use -lm
> > (and -lc).
> > libm.a/libc.a are symlinked to libcygwin.a and this is linked
> > against every
> > program by default. I ran into troubles and stackdumps too, 
> when linking
> > with -lm. I think there's more about this problem in the archives.
> >
> > Karsten
> >
> 
> 

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

RE: problem with dynamic_cast

[Kris Thielemans]

Dear Karsten,

yes, that's seems to be it. Many thanks !

I also found the relevant emails in the archive now (I was looking for RTTI
and dynamic_cast, but the relevant mails didn't mention those).

For those interested, you could start with:
http://www.delorie.com/archives/thread.cgi?msg=cygwin/2000/05/31/19:11:09


It would be wonderful if somebody could provide me with a patched gcc,
and/or update the distribution.

Thanks again,

Kris


> Hi Kris,
>
> I didn't look at your example, but I think you shouldn't use -lm
> (and -lc).
> libm.a/libc.a are symlinked to libcygwin.a and this is linked
> against every
> program by default. I ran into troubles and stackdumps too, when linking
> with -lm. I think there's more about this problem in the archives.
>
> Karsten
>


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

RE: problem with dynamic_cast

[Fleischer, Karsten (K.)]

Hi Kris,

I didn't look at your example, but I think you shouldn't use -lm (and -lc).
libm.a/libc.a are symlinked to libcygwin.a and this is linked against every
program by default. I ran into troubles and stackdumps too, when linking
with -lm. I think there's more about this problem in the archives.

Karsten

> -----Original Message-----
> From: Kris Thielemans [ mailto:kris.thielemans@ic.ac.uk ]
> Sent: Freitag, 8. September 2000 12:46
> To: Gnuwin
> Cc: gcc-bugs@gcc.gnu.org
> Subject: RE: problem with dynamic_cast
> 
> 
> 
> 
> > -----Original Message-----
> > From: Chris Faylor [ mailto:cgf@cygnus.com ]
> > Sent: 07 September 2000 17:01
> > To: Gnuwin
> > Cc: kris.thielemans@csc.mrc.ac.uk
> > Subject: Re: problem with dynamic_cast
> >
> >
> > This is a c++ problem.  You should probably report this to a c++
> > mailing list.
> 
> I doubt it really, but I send this to a C++ mailing list 
> anyway. I've been
> able to boil it down to something really simple. If the latest gcc
> distribution is that broken, we're all in trouble.
> 
> Summarising: in cygwin 1.1.4, or the gcc (or ld) distributed 
> with it (I've
> installed 1.1.4 yesterday), there is a conflict with using 
> RTTI and using
> the math library.
> 
> 
> Attached is a VERY simple C++ program that uses RTTI, but 
> nothing else.
> Compile it with
> 
> g++ dynamic_cast.cxx -lm
> 
> When you run it, it crashes in the dynamic_cast statement. On 
> the other
> hand, compile it with
> 
> g++ dynamic_cast.cxx
> 
> -> it runs fine (i.e. does essentially nothing).
> 
> 
> 
> 
> More details:
> 
> I'm running NT 4.0 sp5 and cygwin 1.1.4.
> 
> screendump of running g++ -v:
> 
> $ g++ dynamic_cast.cxx -lm -v
> Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/specs
> gcc version 2.95.2 19991024 (release-2)
> 
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe -lang-c++ -v 
> -D__GNUC__=2 -D_
> _GN
> UG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_X86=1 
> -D__STDC__=1 -D__st
> dcal
> l=__attribute__((__stdcall__)) 
> -D__cdecl=__attribute__((__cdecl__)) -D__decl
> spec
> (x)=__attribute__((x)) -D__i386__ -D_X86=1 -D__STDC__=1 
> -D__stdcall=__attrib
> ute_
> _((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) 
> -D__declspec(x)=__attr
> ibut
> e__((x)) -D__i386 -Asystem(winnt) -Acpu(i386) -Amachine(i386) 
> -D__EXCEPTIONS
>  -re
> map -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ 
> -Di686 -Dpentiump
> ro -
> D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ 
> -D__CYGWIN32__ -D__CYGWIN
> __ -
> Dunix -D_WIN32 -DWINNT dynamic_cast.cxx /cygdrive/c/TMP/ccpF3zVU.ii
> GNU CPP version 2.95.2 19991024 (release-2) (80386, BSD syntax)
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include
>  /usr/include
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/include
>  /usr/include
> End of search list.
> The following default directories have been omitted from the 
> search path:
>  /usr/include/g++
>  /usr/X11R6.4/include
>  /usr/local/include
> End of omitted list.
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cc1plus.exe
> /cygdrive/c/TMP/ccpF3zVU.ii
> -quiet -dumpbase dynamic_cast.cc -version -o 
> /cygdrive/c/TMP/ccKbIuaN.s
> GNU C++ version 2.95.2 19991024 (release-2) (i686-pc-cygwin) 
> compiled by GNU
> C v
> ersion 2.95.2 19991024 (release-2).
>  as -o /cygdrive/c/TMP/cc7g2nmV.o /cygdrive/c/TMP/ccKbIuaN.s
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -Bdynamic
> /usr/lib/crt0.o -
> L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
> /cygdrive/c/TMP/cc7g2nmV.o -lstdc++ -lm
> -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
> 
> ld.dump attached is a screendump from running ld --verbose 
> explicitly, after
> removing as much libraries and options I could, while still 
> reproducing the
> crash.
> 
> 
> gdb.dump is a screendump from running gdb on the file
> 

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

RE: problem with dynamic_cast

[Kris Thielemans]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

> -----Original Message-----
> From: Chris Faylor [ mailto:cgf@cygnus.com ]
> Sent: 07 September 2000 17:01
> To: Gnuwin
> Cc: kris.thielemans@csc.mrc.ac.uk
> Subject: Re: problem with dynamic_cast
>
>
> This is a c++ problem.  You should probably report this to a c++
> mailing list.

I doubt it really, but I send this to a C++ mailing list anyway. I've been
able to boil it down to something really simple. If the latest gcc
distribution is that broken, we're all in trouble.

Summarising: in cygwin 1.1.4, or the gcc (or ld) distributed with it (I've
installed 1.1.4 yesterday), there is a conflict with using RTTI and using
the math library.


Attached is a VERY simple C++ program that uses RTTI, but nothing else.
Compile it with

g++ dynamic_cast.cxx -lm

When you run it, it crashes in the dynamic_cast statement. On the other
hand, compile it with

g++ dynamic_cast.cxx

-> it runs fine (i.e. does essentially nothing).




More details:

I'm running NT 4.0 sp5 and cygwin 1.1.4.

screendump of running g++ -v:

$ g++ dynamic_cast.cxx -lm -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/specs
gcc version 2.95.2 19991024 (release-2)

/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe -lang-c++ -v -D__GNUC__=2 -D_
_GN
UG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_X86=1 -D__STDC__=1 -D__st
dcal
l=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__decl
spec
(x)=__attribute__((x)) -D__i386__ -D_X86=1 -D__STDC__=1 -D__stdcall=__attrib
ute_
_((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attr
ibut
e__((x)) -D__i386 -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS
 -re
map -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiump
ro -
D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -D__CYGWIN32__ -D__CYGWIN
__ -
Dunix -D_WIN32 -DWINNT dynamic_cast.cxx /cygdrive/c/TMP/ccpF3zVU.ii
GNU CPP version 2.95.2 19991024 (release-2) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include
 /usr/include
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/include/g++
 /usr/X11R6.4/include
 /usr/local/include
End of omitted list.
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cc1plus.exe
/cygdrive/c/TMP/ccpF3zVU.ii
-quiet -dumpbase dynamic_cast.cc -version -o /cygdrive/c/TMP/ccKbIuaN.s
GNU C++ version 2.95.2 19991024 (release-2) (i686-pc-cygwin) compiled by GNU
C v
ersion 2.95.2 19991024 (release-2).
 as -o /cygdrive/c/TMP/cc7g2nmV.o /cygdrive/c/TMP/ccKbIuaN.s
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -Bdynamic
/usr/lib/crt0.o -
L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
/cygdrive/c/TMP/cc7g2nmV.o -lstdc++ -lm
-lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

ld.dump attached is a screendump from running ld --verbose explicitly, after
removing as much libraries and options I could, while still reproducing the
crash.


gdb.dump is a screendump from running gdb on the file

[-- Attachment #2: dynamic_cast.cxx --]
[-- Type: text/x-c++, Size: 328 bytes --]


class A
{ 
public:
  int a;
  virtual ~A() {}
};

class B : public A
{ 
public:
  int b;
};


class C : public B
{ 
public:
  int c;
};

int f(const A* aptr)
{

  if (const B* bptr =
      dynamic_cast<const B *>(aptr))
    {
      return 0;
    }
  else
  {
    return 1;
  }

    
}

int main()
{

  C c;

  return f(&c);

}

[-- Attachment #3: gdb.dump --]
[-- Type: text/plain, Size: 921 bytes --]

(gdb) r
Starting program: /home/kris/C++/test-gcc/a.exe

Program received signal SIGSEGV, Segmentation fault.
0x80d0 in ?? ()
(gdb) info stack
#0  0x80d0 in ?? ()
#1  0x402054 in __si_type_info::dcast (this=0x4070f4, to=@0x4070e4,
    require_public=1, addr=0x241fd90, sub=0x4070d4, subptr=0x241fd90)
    at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo.cc:76
#2  0x4022a3 in __dynamic_cast (from=0x4059c4 <C type_info function>,
    to=0x405988 <B type_info function>, require_public=1, address=0x241fd90,
    sub=0x405958 <A type_info function>, subptr=0x241fd90)
    at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo2.cc:38
#3  0x40107a in f (aptr=0x241fd90) at dynamic_cast.cxx:25
#4  0x4010fc in main () at dynamic_cast.cxx:43
#5  0x61002272 in _size_of_stack_reserve__ ()
#6  0x61002805 in _size_of_stack_reserve__ ()
#7  0x61002843 in _size_of_stack_reserve__ ()
#8  0x40117d in cygwin_crt0 () at dynamic_cast.cxx:45

[-- Attachment #4: ld.dump --]
[-- Type: text/x-asm, Size: 4541 bytes --]

GNU ld version 2.10.90 (with BFD 2.10.90)
  Supported emulations:
   i386pe
using internal linker script:
==================================================
OUTPUT_FORMAT(pei-i386)
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/i686-pc-cygwin/lib);
ENTRY(_mainCRTStartup)
SECTIONS
{
  .text  __image_base__ + __section_alignment__  : 
  {
     *(.init)
    *(.text)
    *(SORT(.text$*))
    *(.glue_7t)
    *(.glue_7)
     ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; 
			LONG (-1); *(.ctors); *(.ctor); LONG (0); 
     ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; 
			LONG (-1); *(.dtors); *(.dtor);  LONG (0); 
     *(.fini)
    /* ??? Why is .gcc_exc here?  */
     *(.gcc_exc)
     etext = .;
    *(.gcc_except_table)
  }
  /* The Cygwin32 library uses a section to avoid copying certain data
     on fork.  This used to be named ".data".  The linker used
     to include this between __data_start__ and __data_end__, but that
     breaks building the cygwin32 dll.  Instead, we name the section
     ".data_cygwin_nocopy" and explictly include it after __data_end__. */
  .data BLOCK(__section_alignment__) : 
  {
    __data_start__ = . ;
    *(.data)
    *(.data2)
    *(SORT(.data$*))
    __data_end__ = . ;
    *(.data_cygwin_nocopy)
  }
  .rdata BLOCK(__section_alignment__) :
  {
    *(.rdata)
    *(SORT(.rdata$*))
    *(.eh_frame)
  }
  .pdata BLOCK(__section_alignment__) :
  {
    *(.pdata)
  }
  .bss BLOCK(__section_alignment__) :
  {
    __bss_start__ = . ;
    *(.bss)
    *(COMMON)
    __bss_end__ = . ;
  }
  .edata BLOCK(__section_alignment__) :
  {
    *(.edata)
  }
  /DISCARD/ :
  {
    *(.debug$S)
    *(.debug$T)
    *(.debug$F)
    *(.drectve)
  }
  .idata BLOCK(__section_alignment__) :
  {
    /* This cannot currently be handled with grouped sections.
	See pe.em:sort_sections.  */
    SORT(*)(.idata$2)
    SORT(*)(.idata$3)
    /* These zeroes mark the end of the import list.  */
    LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
    SORT(*)(.idata$4)
    SORT(*)(.idata$5)
    SORT(*)(.idata$6)
    SORT(*)(.idata$7)
  }
  .CRT BLOCK(__section_alignment__) :
  { 					
    *(SORT(.CRT$*))
  }
  .endjunk BLOCK(__section_alignment__) :
  {
    /* end is deprecated, don't use it */
     end = .;
     _end = .;
     __end__ = .;
  }
  .rsrc BLOCK(__section_alignment__) :
  { 					
    *(.rsrc)
    *(SORT(.rsrc$*))
  }
  .reloc BLOCK(__section_alignment__) :
  { 					
    *(.reloc)
  }
  .stab BLOCK(__section_alignment__) (NOLOAD) :
  {
    [ .stab ]
  }
  .stabstr BLOCK(__section_alignment__) (NOLOAD) :
  {
    [ .stabstr ]
  }
}


==================================================
attempt to open /usr/lib/crt0.o succeeded
/usr/lib/crt0.o
attempt to open dynamic_cast.o succeeded
dynamic_cast.o
attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a failed
attempt to open /usr/lib/libstdc++.a succeeded
attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libm.a failed
attempt to open /usr/lib/libm.a succeeded
(/usr/lib/libm.a)cygwin_crt0.o
(/usr/lib/libm.a)ds00024.o
(/usr/lib/libm.a)_cygwin_crt0_common.o
(/usr/lib/libm.a)ds00611.o
(/usr/lib/libm.a)dh.o
(/usr/lib/libm.a)ds00540.o
(/usr/lib/libm.a)ds00893.o
(/usr/lib/libm.a)ds00676.o
(/usr/lib/libm.a)ds00812.o
(/usr/lib/libm.a)premain3.o
(/usr/lib/libm.a)premain2.o
(/usr/lib/libm.a)premain1.o
(/usr/lib/libm.a)premain0.o
(/usr/lib/libm.a)ds00594.o
(/usr/lib/libm.a)dt.o
attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a succeeded
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)_eh.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)tinfo.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)tinfo2.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)opdel.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)_ctors.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)frame.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)exception.o
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a)_chkstk.o
attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libcygwin.a failed
attempt to open /usr/lib/libcygwin.a succeeded
(/usr/lib/libcygwin.a)ds00820.o
(/usr/lib/libcygwin.a)ds01089.o
(/usr/lib/libcygwin.a)ds01004.o
(/usr/lib/libcygwin.a)ds00498.o
attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libkernel32.a failed
attempt to open /usr/lib/libkernel32.a succeeded
(/usr/lib/libkernel32.a)ds00290.o
(/usr/lib/libkernel32.a)dh.o
(/usr/lib/libkernel32.a)dt.o
attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/libadvapi32.a failed
attempt to open /usr/lib/libadvapi32.a succeeded

Re: problem with dynamic_cast

[Chris Faylor]

This is a c++ problem.  You should probably report this to a c++ mailing list.
Check out http://sources.redhat.com/ for a list of available mailing lists.

cgf

On Thu, Sep 07, 2000 at 04:50:18PM +0100, Kris Thielemans wrote:
>Hi,
>
>I have a tiny bit more information on this problem.
>
>- I reproduced it on my own NT box, with cygwin 1.1.4 (it does NOT happen
>with B20.1)
>
>- I can reproduce it with a file (attached) that does not need linking with
>any other file (except standard libs).
>* If I do a normal "g++ dynamic_cast8.cxx", the program runs fine
>* If I link it with another file I have "g++ dynamic_cast8.cxx bla.o" it
>crashes.
>
>The other file is also compiled with the same gcc (it's not specific to
>which file exactly).
>
>
>Weird.
>
>Suggestions ?
>
>Kris
>
>
>> -----Original Message-----
>> From: Kris Thielemans [ mailto:kris.thielemans@ic.ac.uk ]
>> Sent: 31 August 2000 15:58
>> To: Gnuwin
>> Subject: problem with dynamic_cast
>>
>>
>> Hi,
>>
>> I have a problem with some of our own C++ software when compiled
>> with gcc on cygwin cygwin v.1.1.4 on Windows NT4.00.1381 (Finnish
>> language). Note that this program runs fine on my own NT 4.0 sp5
>> or sp6 machines running cygwin B20.1 with gcc 2.95.2, and on
>> Solaris with gcc 2.95.2, and on AIX with gcc 2.8.1).
>>
>> The problem occurs when executing a dynamic_cast on a pointer.
>> Any suggestions ?
>>
>>
>> details:
>> ---------
>> The program generates the following error:
>>    0 [main] test_VoxelsOnCartesianGrid 1039 handle_exceptions: Exception:
>> STATUS_ACCESS_VIOLATION
>>    974 [main] test_VoxelsOnCartesianGrid 1039 stackdump: Dumping
>> stack trace
>> to test_VoxelsOnCartesianGrid.exe.stackdump
>> make: *** [run_tests] Segmentation fault (core dumped)
>>
>> The file where it crashes is compiled as follows:
>> g++  -g -D_DEBUG -g  -Wall  -I/home/PPhead/include  -o
>> debug/VoxelsOnCartesianGrid.o -c VoxelsOnCartesianGrid.cxx
>>
>>
>> When running the program in gdb, the stack trace after the crash is:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x611e4 in ?? ()
>> (gdb) info stack
>> #0  0x611e4 in ?? ()
>> #1  0x41e484 in __si_type_info::dcast (this=0x460520, to=@0x4604c0,
>>     require_public=1, addr=0xa057e90, sub=0x460280, subptr=0xa057e90)
>>     at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo.cc:76
>> #2  0x41e6d3 in __dynamic_cast (
>>     from=0x441658 <Tomo::ProjDataInfoCylindricalArcCorr type_info
>> function>,
>>     to=0x4415a4 <Tomo::ProjDataInfoCylindrical type_info function>,
>>     require_public=1, address=0xa057e90,
>>     sub=0x441544 <Tomo::ProjDataInfo type_info function>,
>> subptr=0xa057e90)
>>     at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo2.cc:38
>> #3  0x40ddda in Tomo::find_sampling_and_z_size (z_sampling=@0x266f898,
>>     s_sampling=@0x266f894, z_size=@0x266f89c,
>> proj_data_info_ptr=0xa057e90)
>>     at VoxelsOnCartesianGrid.cxx:45
>> #4  0x4325e8 in
>> Tomo::VoxelsOnCartesianGrid<float>::VoxelsOnCartesianGrid (
>>     this=0x266fc00, proj_data_info=@0xa057e90, zoom=2.29999995,
>>     origin=@0x266fd10, make_xy_size_odd=false) at
>> VoxelsOnCartesianGrid.cxx:138
>> #5  0x4022a6 in Tomo::VoxelsOnCartesianGridTests::run_tests
>> (this=0x266fd60)
>>     at test_VoxelsOnCartesianGrid.cxx:103
>> #6  0x403174 in main () at test_VoxelsOnCartesianGrid.cxx:180
>> #7  0x61002272 in _size_of_stack_reserve__ ()
>> #8  0x61002805 in _size_of_stack_reserve__ ()
>> #9  0x61002843 in _size_of_stack_reserve__ ()
>> #10 0x41cdd5 in cygwin_crt0 ()
>>
>>
>> This seems to say there is something wrong in the dynamic_cast
>> statement on that line, which looks as follows:
>>   if (const ProjDataInfoCylindrical*
>>         proj_data_info_cyl_ptr =
>> 	dynamic_cast<const ProjDataInfoCylindrical*>(proj_data_info_ptr))
>>   { ...}
>>
>> By the way, if you check the stack trace, you'll see that the
>> dynamic cast is from a ProjDataInfoCylindricalArcCorr * to a
>> ProjDataInfoCylindrical *, where ProjDataInfoCylindricalArcCorr
>> is derived from ProjDataInfoCylindrical. (Not that it should
>> crash in any case).
>>
>>
>> Thanks !
>>
>>
>>
>> Kris Thielemans
>> (kris.thielemans@ic.ac.uk)
>> MRC Cyclotron Unit,
>> Hammersmith Hospital,
>> DuCane Rd,London W12 0NN, United Kingdom
>>
>> Phone on :   +44 (020)8383 3731
>> FAX on :     +44 (020)8383 2029
>>
>> NEW web site address:
>> http://www.cu.mrc.ac.uk/~kris


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

-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourceware.cygnus.com/         http://www.redhat.com/

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

RE: problem with dynamic_cast

[Kris Thielemans]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

Hi,

I have a tiny bit more information on this problem.

- I reproduced it on my own NT box, with cygwin 1.1.4 (it does NOT happen
with B20.1)

- I can reproduce it with a file (attached) that does not need linking with
any other file (except standard libs).
* If I do a normal "g++ dynamic_cast8.cxx", the program runs fine
* If I link it with another file I have "g++ dynamic_cast8.cxx bla.o" it
crashes.

The other file is also compiled with the same gcc (it's not specific to
which file exactly).


Weird.

Suggestions ?

Kris


> -----Original Message-----
> From: Kris Thielemans [ mailto:kris.thielemans@ic.ac.uk ]
> Sent: 31 August 2000 15:58
> To: Gnuwin
> Subject: problem with dynamic_cast
>
>
> Hi,
>
> I have a problem with some of our own C++ software when compiled
> with gcc on cygwin cygwin v.1.1.4 on Windows NT4.00.1381 (Finnish
> language). Note that this program runs fine on my own NT 4.0 sp5
> or sp6 machines running cygwin B20.1 with gcc 2.95.2, and on
> Solaris with gcc 2.95.2, and on AIX with gcc 2.8.1).
>
> The problem occurs when executing a dynamic_cast on a pointer.
> Any suggestions ?
>
>
> details:
> ---------
> The program generates the following error:
>    0 [main] test_VoxelsOnCartesianGrid 1039 handle_exceptions: Exception:
> STATUS_ACCESS_VIOLATION
>    974 [main] test_VoxelsOnCartesianGrid 1039 stackdump: Dumping
> stack trace
> to test_VoxelsOnCartesianGrid.exe.stackdump
> make: *** [run_tests] Segmentation fault (core dumped)
>
> The file where it crashes is compiled as follows:
> g++  -g -D_DEBUG -g  -Wall  -I/home/PPhead/include  -o
> debug/VoxelsOnCartesianGrid.o -c VoxelsOnCartesianGrid.cxx
>
>
> When running the program in gdb, the stack trace after the crash is:
> Program received signal SIGSEGV, Segmentation fault.
> 0x611e4 in ?? ()
> (gdb) info stack
> #0  0x611e4 in ?? ()
> #1  0x41e484 in __si_type_info::dcast (this=0x460520, to=@0x4604c0,
>     require_public=1, addr=0xa057e90, sub=0x460280, subptr=0xa057e90)
>     at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo.cc:76
> #2  0x41e6d3 in __dynamic_cast (
>     from=0x441658 <Tomo::ProjDataInfoCylindricalArcCorr type_info
> function>,
>     to=0x4415a4 <Tomo::ProjDataInfoCylindrical type_info function>,
>     require_public=1, address=0xa057e90,
>     sub=0x441544 <Tomo::ProjDataInfo type_info function>,
> subptr=0xa057e90)
>     at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo2.cc:38
> #3  0x40ddda in Tomo::find_sampling_and_z_size (z_sampling=@0x266f898,
>     s_sampling=@0x266f894, z_size=@0x266f89c,
> proj_data_info_ptr=0xa057e90)
>     at VoxelsOnCartesianGrid.cxx:45
> #4  0x4325e8 in
> Tomo::VoxelsOnCartesianGrid<float>::VoxelsOnCartesianGrid (
>     this=0x266fc00, proj_data_info=@0xa057e90, zoom=2.29999995,
>     origin=@0x266fd10, make_xy_size_odd=false) at
> VoxelsOnCartesianGrid.cxx:138
> #5  0x4022a6 in Tomo::VoxelsOnCartesianGridTests::run_tests
> (this=0x266fd60)
>     at test_VoxelsOnCartesianGrid.cxx:103
> #6  0x403174 in main () at test_VoxelsOnCartesianGrid.cxx:180
> #7  0x61002272 in _size_of_stack_reserve__ ()
> #8  0x61002805 in _size_of_stack_reserve__ ()
> #9  0x61002843 in _size_of_stack_reserve__ ()
> #10 0x41cdd5 in cygwin_crt0 ()
>
>
> This seems to say there is something wrong in the dynamic_cast
> statement on that line, which looks as follows:
>   if (const ProjDataInfoCylindrical*
>         proj_data_info_cyl_ptr =
> 	dynamic_cast<const ProjDataInfoCylindrical*>(proj_data_info_ptr))
>   { ...}
>
> By the way, if you check the stack trace, you'll see that the
> dynamic cast is from a ProjDataInfoCylindricalArcCorr * to a
> ProjDataInfoCylindrical *, where ProjDataInfoCylindricalArcCorr
> is derived from ProjDataInfoCylindrical. (Not that it should
> crash in any case).
>
>
> Thanks !
>
>
>
> Kris Thielemans
> (kris.thielemans@ic.ac.uk)
> MRC Cyclotron Unit,
> Hammersmith Hospital,
> DuCane Rd,London W12 0NN, United Kingdom
>
> Phone on :   +44 (020)8383 3731
> FAX on :     +44 (020)8383 2029
>
> NEW web site address:
> http://www.cu.mrc.ac.uk/~kris

[-- Attachment #2: dynamic_cast8.cxx --]
[-- Type: text/x-c++, Size: 5730 bytes --]

#define END_NAMESPACE_TOMO
#define START_NAMESPACE_TOMO
#define USING_NAMESPACE_TOMO

 
template <class NUMBER> 
inline NUMBER square(const NUMBER &x) { return x*x; }

#include <iostream>

#ifndef __ProjDataInfo_H__
#define __ProjDataInfo_H__



START_NAMESPACE_TOMO

template <typename elemT> class Sinogram;
template <typename elemT> class Viewgram;
template <typename elemT> class SegmentByView;
template <typename elemT> class SegmentBySinogram;
template <typename elemT> class RelatedViewgrams;
class DataSymmetriesForViewSegmentNumbers;
class ViewSegmentNumbers;
class PMessage;

class ProjDataInfo
{
  
public:

  
  
  /************ constructors ***********/
  // TODO should probably be protected

  //! Construct an empty object
  inline  ProjDataInfo();


  //! Standard trick for a 'virtual copy-constructor' 
  virtual ProjDataInfo* clone() const = 0;

  //! Destructor
  virtual ~ProjDataInfo() {}

  /**************** member functions *********/

  // TODOdoc coordinate system
  //! Get tangent of the co-polar angle, tan(theta)
  virtual float get_tantheta(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const =0;
  //! Get azimuthal angle phi
  virtual float get_phi(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const =0;
  
  //! Get value of the (roughly) axial coordinate in the projection plane (in mm)
  virtual float get_t(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const =0;

  //! Get value of the tangential coordinate in the projection plane (in mm)
  virtual float get_s(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const =0;
  
  
private:

  int min_view_num;
  int max_view_num;
  int min_tangential_pos_num;
  int max_tangential_pos_num;
  
};

END_NAMESPACE_TOMO

//#include "ProjDataInfo.inl"
//
// @(#)ProjDataInfo.inl	1.1: 00/06/14
//

START_NAMESPACE_TOMO


ProjDataInfo::ProjDataInfo()
{}
  


END_NAMESPACE_TOMO


#endif //  __ProjDataInfo_H__

#ifndef __ProjDataInfoCylindrical_H__
#define __ProjDataInfoCylindrical_H__


//#include"ProjDataInfo.h"

START_NAMESPACE_TOMO
/*!
  \ingroup buildblock 
  \brief projection data info for data corresponding to a 
  'cylindrical' sampling.

  These data are organised by ring differences (allowing for
  merging of some ring differences into 1 segment). It is general
  enough to have both the CTI 'spanned' format, and the GE Advance
  format.
*/
// TODOdoc more
class ProjDataInfoCylindrical: public ProjDataInfo
{

public:
  //! Constructors
  inline ProjDataInfoCylindrical();
		       
  inline float get_phi(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const; 
 
  inline float get_t(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const;



protected:

  float azimuthal_angle_sampling;
  float ring_radius;

private:
  float ring_spacing;

};


END_NAMESPACE_TOMO

//#include "ProjDataInfoCylindrical.inl"

//
// @(#)ProjDataInfoCylindrical.inl	1.1: 00/06/14
//
START_NAMESPACE_TOMO

ProjDataInfoCylindrical::ProjDataInfoCylindrical()
{}


float
ProjDataInfoCylindrical::get_phi(int segment_num,int view_num,int axial_position_num, int transaxial_position_num)const
{ return view_num*azimuthal_angle_sampling;}

float
ProjDataInfoCylindrical::get_t(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const
{return axial_position_num;}





END_NAMESPACE_TOMO


  

#endif

#ifndef __ProjDataInfoCylindricalArcCorr_H__
#define __ProjDataInfoCylindricalArcCorr_H__


//#include "ProjDataInfoCylindrical.h"

START_NAMESPACE_TOMO

/*!
  \ingroup buildblock 
  \brief projection data info for arc-corrected data
  */
class ProjDataInfoCylindricalArcCorr : public ProjDataInfoCylindrical
{

public:
  //! Constructors
  inline ProjDataInfoCylindricalArcCorr();

  
  inline virtual float get_tantheta(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const; 
  inline virtual float get_s(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const;
  inline ProjDataInfo* clone() const;

private:
  
  float bin_size;
  

};

END_NAMESPACE_TOMO

//#include "ProjDataInfoCylindricalArcCorr.inl"

//
// @(#)ProjDataInfoCylindricalArcCorr.inl	1.1: 00/06/14
//

START_NAMESPACE_TOMO
ProjDataInfoCylindricalArcCorr:: ProjDataInfoCylindricalArcCorr()

{}

float
ProjDataInfoCylindricalArcCorr::get_s(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const
{return transaxial_position_num*bin_size;}


float
ProjDataInfoCylindricalArcCorr::get_tantheta(int segment_num,int view_num,int axial_position_num, int transaxial_position_num) const
{
  return
    (2*sqrt(square(ring_radius)-square(get_s(segment_num,view_num,axial_position_num, transaxial_position_num))));
  
}





ProjDataInfo*
ProjDataInfoCylindricalArcCorr::clone() const
{
 return static_cast<ProjDataInfo*>(new ProjDataInfoCylindricalArcCorr(*this));

}


END_NAMESPACE_TOMO


#endif

//#include "ProjDataInfoCylindricalArcCorr.h"


USING_NAMESPACE_TOMO

// a local help function to find appropriate sizes etc.

static void find_sampling_and_z_size(
				 const ProjDataInfo* proj_data_info_ptr)
{

  // first z- things

  const ProjDataInfoCylindrical*
        proj_data_info_cyl_ptr = 
    dynamic_cast<const ProjDataInfoCylindrical*>(proj_data_info_ptr);

  if (proj_data_info_cyl_ptr)
   {
     std::cerr << "OK !\n";
   }
  else
    {
      std::cerr << " Not OK!\n";
    }
}


int main()
{

  ProjDataInfo * proj_data_info_ptr = 
    new ProjDataInfoCylindricalArcCorr;

  find_sampling_and_z_size(proj_data_info_ptr);
  return 0;

}

problem with dynamic_cast

[Kris Thielemans]

Hi,

I have a problem with some of our own C++ software when compiled with gcc on
cygwin cygwin v.1.1.4 on Windows NT4.00.1381 (Finnish language). Note that
this program runs fine on my own NT 4.0 sp5 or sp6 machines running cygwin
B20.1 with gcc 2.95.2, and on Solaris with gcc 2.95.2, and on AIX with gcc
2.8.1).

The problem occurs when executing a dynamic_cast on a pointer.
Any suggestions ?


details:
---------
The program generates the following error:
   0 [main] test_VoxelsOnCartesianGrid 1039 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   974 [main] test_VoxelsOnCartesianGrid 1039 stackdump: Dumping stack trace
to test_VoxelsOnCartesianGrid.exe.stackdump
make: *** [run_tests] Segmentation fault (core dumped)

The file where it crashes is compiled as follows:
g++  -g -D_DEBUG -g  -Wall  -I/home/PPhead/include  -o
debug/VoxelsOnCartesianGrid.o -c VoxelsOnCartesianGrid.cxx


When running the program in gdb, the stack trace after the crash is:
Program received signal SIGSEGV, Segmentation fault.
0x611e4 in ?? ()
(gdb) info stack
#0  0x611e4 in ?? ()
#1  0x41e484 in __si_type_info::dcast (this=0x460520, to=@0x4604c0,
    require_public=1, addr=0xa057e90, sub=0x460280, subptr=0xa057e90)
    at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo.cc:76
#2  0x41e6d3 in __dynamic_cast (
    from=0x441658 <Tomo::ProjDataInfoCylindricalArcCorr type_info function>,
    to=0x4415a4 <Tomo::ProjDataInfoCylindrical type_info function>,
    require_public=1, address=0xa057e90,
    sub=0x441544 <Tomo::ProjDataInfo type_info function>, subptr=0xa057e90)
    at /cygnus/netrel/src/gcc-2.95.2-2/gcc/cp/tinfo2.cc:38
#3  0x40ddda in Tomo::find_sampling_and_z_size (z_sampling=@0x266f898,
    s_sampling=@0x266f894, z_size=@0x266f89c, proj_data_info_ptr=0xa057e90)
    at VoxelsOnCartesianGrid.cxx:45
#4  0x4325e8 in Tomo::VoxelsOnCartesianGrid<float>::VoxelsOnCartesianGrid (
    this=0x266fc00, proj_data_info=@0xa057e90, zoom=2.29999995,
    origin=@0x266fd10, make_xy_size_odd=false) at
VoxelsOnCartesianGrid.cxx:138
#5  0x4022a6 in Tomo::VoxelsOnCartesianGridTests::run_tests (this=0x266fd60)
    at test_VoxelsOnCartesianGrid.cxx:103
#6  0x403174 in main () at test_VoxelsOnCartesianGrid.cxx:180
#7  0x61002272 in _size_of_stack_reserve__ ()
#8  0x61002805 in _size_of_stack_reserve__ ()
#9  0x61002843 in _size_of_stack_reserve__ ()
#10 0x41cdd5 in cygwin_crt0 ()


This seems to say there is something wrong in the dynamic_cast statement on
that line, which looks as follows:
  if (const ProjDataInfoCylindrical*
        proj_data_info_cyl_ptr =
	dynamic_cast<const ProjDataInfoCylindrical*>(proj_data_info_ptr))
  { ...}

By the way, if you check the stack trace, you'll see that the dynamic cast
is from a ProjDataInfoCylindricalArcCorr * to a ProjDataInfoCylindrical *,
where ProjDataInfoCylindricalArcCorr is derived from
ProjDataInfoCylindrical. (Not that it should crash in any case).


Thanks !



Kris Thielemans
(kris.thielemans@ic.ac.uk)
MRC Cyclotron Unit,
Hammersmith Hospital,
DuCane Rd,London W12 0NN, United Kingdom

Phone on :   +44 (020)8383 3731
FAX on :     +44 (020)8383 2029

NEW web site address:
http://www.cu.mrc.ac.uk/~kris


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