Re: c++/8847: dynamic_cast segfaults with shared lib

Re: c++/8847: dynamic_cast segfaults with shared lib

[Reinier.Bezuidenhout]

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

From: <Reinier.Bezuidenhout@nokia.com>
To: <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
   <hans.utz@informatik.uni-ulm.de>, <gcc-bugs@gcc.gnu.org>,
   <nobody@gcc.gnu.org>
Cc:  
Subject: Re: c++/8847: dynamic_cast segfaults with shared lib
Date: Mon, 9 Dec 2002 16:41:28 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D=
 gcc&pr=3D8847
 
 Hi ...
 
 I'm running into a similar problem on my system.  Mine is a bit more =
 difficult to trace since it involves a Java JNI call.  =20
 
 I have an application that loads a shared library that uses the =
 dynamic_cast.  When using the shared library from a c++ program on the =
 command line, it works fine.  When I do it via a JNI call in segfaults.  =
 I tried the smaller sample program and that too crashed in the same way.
 
 Here is some info:
 
 [root@comet jni]# gcc -v
 Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
 gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
 
 [root@comet jni]# java -version
 java version "1.4.1_01"
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
 Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
 
 
 Unfortunately here I can't recompile the JVM .... The java was compiled =
 with :
 GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)=20
 (This is java 1.4.1_01 release)
 
 
 Should I try compiling by lib with gcc 2.91.66 ?? =20
 
 Thanks
 Reinier
 
 
 
 

Re: c++/8847: dynamic_cast segfaults with shared lib

[bangerth]

Synopsis: dynamic_cast segfaults with shared lib

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Mon Jan 27 15:54:55 2003
State-Changed-Why:
    Not a bug in gcc, but a name conflict with libGLU.
    
    Thanks to Christoph Wiedemann for the detective work of
    finding this out!
    
    W.

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

Re: c++/8847: dynamic_cast segfaults with shared lib

[christoph.wiedemann]

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

From: <christoph.wiedemann@daimlerchrysler.com>
To: <nobody@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
        <hans.utz@informatik.uni-ulm.de>, <gcc-prs@gcc.gnu.org>,
        <gcc-gnats@gcc.gnu.org>, <himself@markus-hillebrand.de>
Cc:  
Subject: Re: c++/8847: dynamic_cast segfaults with shared lib
Date: Mon, 27 Jan 2003 14:00:23 +0100

  =20
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&databas=
 e=3Dgcc&pr=3D88
 47
 
 Hi,
 
 i had the same problem with linking against libGLU.so.=20
 It seems to be that dynamic_cast is internally using the symbol __dynam=
 ic_cast,=20
 which is exported by libGLU:
 
 >nm /usr/lib/libGLU.so | grep dynamic_cast
 >0007b1d4  T  __dynamic_cast
 
 but also by libstdc++:
 
 >nm /usr/local/lib/libstdc++.so | grep dynamic_cast
 >00050a00  T  __dynamic_cast
 
 In my case, it is enough to export the environment variable LD_PRELOAD =
 to the=20
 /usr/local/lib/libstdc++.so, or to pass the linker flag -lstdc++ as the=
  _first_=20
 -l option.
 
 Kind Regards,
 -----------------------------------------------------------------------=
 ---------
 ----- Christoph Wiedemann=20
 DaimlerChrysler AG, Research Center Ulm=20
 P.O. Box 2360, 89013 Ulm, Germany=20
 
 Phone: +49 731 505 4123=20
 e-mail: christoph.wiedemann@daimlerchrysler.com=20
 -----------------------------------------------------------------------=
 ---------
 ----- =

Re: c++/8847: dynamic_cast segfaults with shared lib

[Markus Hillebrand]

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

From: Markus Hillebrand <himself@markus-hillebrand.de>
To: gcc-gnats@gcc.gnu.org,
 gcc-prs@gcc.gnu.org,
 hans.utz@informatik.uni-ulm.de,
 gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/8847: dynamic_cast segfaults with shared lib
Date: Sat, 18 Jan 2003 01:30:44 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=8847
 
 Hi!
 
 Maybe I can provide a hint on that problem ...
 
 Today I had some similiar problems by updating some
 of my libraries and some other sources. I also had a
 segmentation-fault on a dynamic_cast. After reading this
 posting I remembered, that problems can occur, when
 using shared libraries are used without using the -fPIC
 compiler option.
 
 I recompiled the library (omniORB-4.0.0, RedHat 7.3 x-86 Linux,
 with gcc-3.2.1) and my source with this option and the problem
 disappeared. I think this is some nasty thing, that there is no
 (linker) check about that. Maybe someone will provide some more
 comfortable checkings here ...
 
 	With best regards,
 	M. Hillebrand
 

Re: c++/8847: dynamic_cast segfaults with shared lib

[Hans Utz]

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

From: Hans Utz <hans.utz@informatik.uni-ulm.de>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org,
 	gcc-prs@gcc.gnu.org, hans.utz@informatik.uni-ulm.de,
 	nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/8847: dynamic_cast segfaults with shared lib
Date: Fri, 06 Dec 2002 18:19:18 +0100

 bangerth@dealii.org wrote:
 > 
 > Synopsis: dynamic_cast segfaults with shared lib
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Fri Dec  6 09:12:57 2002
 > State-Changed-Why:
 >     I can confirm the problem with a slightly smaller program:
 >     ------------------------------
 >     struct Foo {
 >       virtual ~Foo(){};
 >     };
 > 
 >     struct myBar : public Foo {
 >       virtual ~myBar(){};
 >     };
 > 
 >     int main(int, char **)
 >     {
 >       dynamic_cast<myBar *>((Foo*)new myBar());
 > 
 >       return 0;
 >     }
 >     ----------------------------------
 >     Linking with libGLU alone suffices to crash the program.
 > 
 >     However: on my system, which is very much like yours,
 >     libGLU and libGL are located in /usr/lib, i.e. are
 >     system libraries and are thus probably compiled with
 >     gcc 2.95. In contrast to libGL, libGLU has C++ symbols
 >     in it, so I am pretty sure that the problem stems from
 >     the ABI incompatibilities between the 2.95 C++ compiler
 >     and the 3.2 C++ compiler. This has to be expected. Linking
 >     C++ libraries together that have not been created with the
 >     same compiler asks for trouble (or at least did, prior to
 >     the standard gcc is trying to follow since 3.2). Can you
 >     report what happens if you try to use a libGLU that is
 >     compiled with the same compiler as the one you use
 >     for the rest of the project, i.e. 3.2.1?
 > 
 >     Thanks
 >       Wolfgang
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8847
 
 I didn't know libGLU contains C++ symbols. I will look for the sources, compile
 them and try again.
 
 Thanks,
 Hans

Re: c++/8847: dynamic_cast segfaults with shared lib

[bangerth]

Synopsis: dynamic_cast segfaults with shared lib

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Fri Dec  6 09:12:57 2002
State-Changed-Why:
    I can confirm the problem with a slightly smaller program:
    ------------------------------
    struct Foo {
      virtual ~Foo(){};
    };
    
    struct myBar : public Foo {
      virtual ~myBar(){};
    };
    
    int main(int, char **)
    {
      dynamic_cast<myBar *>((Foo*)new myBar());
    
      return 0;
    }
    ----------------------------------
    Linking with libGLU alone suffices to crash the program.
    
    However: on my system, which is very much like yours,
    libGLU and libGL are located in /usr/lib, i.e. are
    system libraries and are thus probably compiled with
    gcc 2.95. In contrast to libGL, libGLU has C++ symbols
    in it, so I am pretty sure that the problem stems from
    the ABI incompatibilities between the 2.95 C++ compiler
    and the 3.2 C++ compiler. This has to be expected. Linking
    C++ libraries together that have not been created with the
    same compiler asks for trouble (or at least did, prior to
    the standard gcc is trying to follow since 3.2). Can you
    report what happens if you try to use a libGLU that is
    compiled with the same compiler as the one you use
    for the rest of the project, i.e. 3.2.1?
    
    Thanks
      Wolfgang

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

c++/8847: dynamic_cast segfaults with shared lib

[hans.utz]

>Number:         8847
>Category:       c++
>Synopsis:       dynamic_cast segfaults with shared lib
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 06 08:56:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Hans Utz
>Release:        3.2.1
>Organization:
>Environment:
Linux SuSE 7.3 box (Athlon)
gcc -v:
Reading specs from /data1/hutz/3.2/gcc/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
Configured with: ../gcc-3.2.1/configure --prefix=/data1/hutz/3.2/gcc
Thread model: posix
gcc version 3.2.1
>Description:
When compiling the attached minimal test program linking it
with libGLU.so.1.3 and libGL, the execution fails with a 
segmentation fault on the dynamic_cast statement. - 
When compiling with just libGL or no library everything 
works fine.

g++ Test.cc              # okay
g++ Test.cc -lGL         # okay
g++ Test.cc -lGLU -lGL   # segfault

I know that it is not a good test case, as it depends on
some library on some distribution, but maybe it's a
starting point for a better test case. - As I don't know
how to find out about what's going wrong when linking with 
libGLU I'm stuck.

Thanks,
Hans 
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="Test.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Test.cc"

c3RydWN0IEZvbwp7CiAgdmlydHVhbCB+Rm9vKCk7Cn07CgpGb286On5Gb28oKSB7fQoKc3RydWN0
IEJhciA6IHB1YmxpYyBGb28KewogIHZpcnR1YWwgfkJhcigpOwp9OwoKQmFyOjp+QmFyKCkge30K
CmludCBtYWluKGludCwgY2hhciAqKikKewogIEZvbyAqIGZvbyA9IG5ldyBCYXIoKTsKICBCYXIg
KiBiYXIgPSBkeW5hbWljX2Nhc3Q8QmFyICo+KGZvbyk7CgogIHJldHVybiAwOwp9Cg==