From: Allen Bierbaum (allenb++at++vrac.iastate.edu)
Date: 06/26/2001 10:13:32
I have seen this type of behavior under Linux with Performer with the
more recent versions of redhat.
The code that I have works correctly on Irix and on RH 6.x but seg
faults when used on redhat 7.x during dynamic casts. If I get rid of
Performer, then everything works fine.
-Allen
Markus von der Heyde wrote:
>
> Jean-Francois Panisset writes:
> > <200106210900.CAA21533++at++holodeck.engr.sgi.com>info-performer Mailing List write
> > >
> > > From: Markus von der Heyde <MvdH++at++Kyb.Tuebingen.MPG.de>
> > > Date: Wed, 20 Jun 2001 12:09:35 +0200
> > > Subject: using dynamic_cast with Performer lib
> > > Reply-To: Markus.von.der.Heyde++at++Tuebingen.MPG.de
> > >
> > >Hi,
> > >
> > >as soon as I integrate a dynamic_cast into a program with is linked
> > >with the Performer lib (-lpf) I get a segmentation fault.
> > >
> > >(gdb) bt
> > >#0 0x0 in ?? ()
> > >#1 0x40712568 in __user_type_info::dyncast (this=3D0x8049b38, boff=3D0=
> > >,=20
> > > target=3D++at++0x8049b38, objptr=3D0x8055078, subtype=3D++at++0x8049b44, subp=
> > >tr=3D0x8055078)
> > > from /usr/lib/libstdc++-libc6.2-2.so.3
> >
> > I've run into these kinds of problems myself, and they were caused
> > by having two separate versions of the C++ runtime loaded at the
> > same time. Try:
> >
> > ldd my_app_name
>
> coriander(mvdh):dynamic_cast>g++ -o dynamic dynamic_cast.cpp
> coriander(mvdh):dynamic_cast>ldd ./dynamic
> libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40025000)
> libm.so.6 => /lib/libm.so.6 (0x40068000)
> libc.so.6 => /lib/libc.so.6 (0x40088000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> and that version works fine. The other (with performer) look like:
>
> coriander(mvdh):dynamic_cast>g++ -o dynamic-lpf dynamic_cast.cpp -lpf
> coriander(mvdh):dynamic_cast>ldd ./dynamic-lpf
> libpf.so.1 => /usr/lib/libpf.so.1 (0x40025000)
> libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x406ea000)
> libm.so.6 => /lib/libm.so.6 (0x4072d000)
> libc.so.6 => /lib/libc.so.6 (0x4074d000)
> libGL.so.1 => /usr/lib/libGL.so.1 (0x40876000)
> libGLU.so.1 => /usr/lib/libGLU.so.1 (0x408ad000)
> libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x408ca000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40917000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x409f6000)
> libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40a04000)
> libdl.so.2 => /lib/libdl.so.2 (0x40a1a000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40a1d000)
> libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40bff000)
> libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40c09000)
>
> and of cause - this version segfaults.
>
> I can not see any additional libc versions which is not already in the
> running version.
>
> >
> > If you have two separate versions of libstdc++ dynamically linked
> > against your app, that's the kind of problems you will run into.
> > This typically happens when you are using gcc 2.96 (which will
> > link against /usr/lib/libstdc++-3-...), but are also linking
> > against DSOs compiled with an older version of the compiler,
> > themselves referencing /usr/lib/libstdc++-2-....
>
> should they not show up in any of the ldd of the mentioned DSOs from
> above? I tried them all - but they seam clean to me.
>
> > If this is the case, run ldd on each of the DSOs you are linking against
> > to find the culprit. Once you have found it, if you have source for
> > that DSO, recompile it with gcc 2.96. Otherwise, you might be able
> > to fool the runtime loader by playing games with symlinks in /usr/lib
> > to make sure that everyone gets /usr/lib/libstdc++-3..., although
> > that's a bit tricky (and everytime you reinstall stuff on your
> > machine, the symlinks may get overwritten back to what they were
> > before).
>
> ok - lets try wheather on of the other system libs causes problems:
> 1) the version WITHOUT libpf
> coriander(mvdh):dynamic_cast>g++ -o dynamic-lmulti dynamic_cast.cpp -L/usr/X11R6/lib -lGL -lGLU -lXt -lX11 -lXext -lXmu -ldl -lGLcore -lSM -lICE -lm -lc -lstdc++
> 2) the version WITH libpf
> coriander(mvdh):dynamic_cast>g++ -o dynamic-lmulti-lpf dynamic_cast.cpp -L/usr/X11R6/lib -lGL -lGLU -lXt -lX11 -lXext -lXmu -ldl -lGLcore -lSM -lICE -lm -lc -lstdc++ -lpf
>
> 3) get the ldd output and compare:
> coriander(mvdh):dynamic_cast>ldd ./dynamic-lmulti > lddmulti
> coriander(mvdh):dynamic_cast>ldd ./dynamic-lmulti-lpf > lddpf
> coriander(mvdh):dynamic_cast>diff lddmulti lddpf
> 12,13c12,14
> < libm.so.6 => /lib/libm.so.6 (0x40411000)
> < libc.so.6 => /lib/libc.so.6 (0x40431000)
> ---
> > libpf.so.1 => /usr/lib/libpf.so.1 (0x40411000)
> > libm.so.6 => /lib/libm.so.6 (0x40ad6000)
> > libc.so.6 => /lib/libc.so.6 (0x40af7000)
>
> So - it looks like libpf is the only new one between the two binaries - and
> of cause the one with libpf segfaults again.
>
> Last try - delayed loading during runtime:
>
> coriander(mvdh):dynamic_cast>strace ./dynamic-lmulti 2>&1 | grep lib | grep open | grep -v '= -1' | sort | uniq -c
> 11 open("/lib/libc.so.6", O_RDONLY) = 3
> 2 open("/lib/libdl.so.2", O_RDONLY) = 3
> 3 open("/lib/libm.so.6", O_RDONLY) = 3
> 4 open("/usr/X11R6/lib/libICE.so.6", O_RDONLY) = 3
> 3 open("/usr/X11R6/lib/libSM.so.6", O_RDONLY) = 3
> 5 open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) = 3
> 3 open("/usr/X11R6/lib/libXext.so.6", O_RDONLY) = 3
> 1 open("/usr/X11R6/lib/libXmu.so.6", O_RDONLY) = 3
> 2 open("/usr/X11R6/lib/libXt.so.6", O_RDONLY) = 3
> 1 open("/usr/lib/libGL.so.1", O_RDONLY) = 3
> 1 open("/usr/lib/libGLU.so.1", O_RDONLY) = 3
> 2 open("/usr/lib/libGLcore.so.1", O_RDONLY) = 3
> 1 open("/usr/lib/libstdc++-libc6.2-2.so.3", O_RDONLY) = 3
>
> coriander(mvdh):dynamic_cast>strace ./dynamic-lmulti-lpf 2>&1 | grep lib | grep open | grep -v '= -1' | sort | uniq -c
> 11 open("/lib/libc.so.6", O_RDONLY) = 3
> 3 open("/lib/libdl.so.2", O_RDONLY) = 3
> 4 open("/lib/libm.so.6", O_RDONLY) = 3
> 4 open("/usr/X11R6/lib/libICE.so.6", O_RDONLY) = 3
> 3 open("/usr/X11R6/lib/libSM.so.6", O_RDONLY) = 3
> 6 open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) = 3
> 4 open("/usr/X11R6/lib/libXext.so.6", O_RDONLY) = 3
> 2 open("/usr/X11R6/lib/libXmu.so.6", O_RDONLY) = 3
> 3 open("/usr/X11R6/lib/libXt.so.6", O_RDONLY) = 3
> 2 open("/usr/lib/libGL.so.1", O_RDONLY) = 3
> 2 open("/usr/lib/libGLU.so.1", O_RDONLY) = 3
> 2 open("/usr/lib/libGLcore.so.1", O_RDONLY) = 3
> 1 open("/usr/lib/libpf.so.1", O_RDONLY) = 3
> 1 open("/usr/lib/libstdc++-libc6.2-2.so.3", O_RDONLY) = 3
>
> Again - the libpf is the only new one during runtime and it does cause
> the segfault.
>
> > Isn't the lack of a standard C++ ABI a great thing? And it will
> > only get worse with gcc 3.0, which breaks that completely once again...
>
> I don't want to comment on that and cause another war of flames - but
> I do would like to suggest to recompile libpf with the appropriate
> switches to avoid the problems above. Are there any other suggestion -
> I would be happy to try something else in between ;-) I mean something
> other than leaving the dynamic_cast alone and use the static_cast
> instead...
>
> Thanks,
> Markus
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2b29 : Tue Jun 26 2001 - 09:58:41 PDT