Re: using dynamic_cast with Performer lib

New Message Reply Date view Thread view Subject view Author view

From: Allen Bierbaum (allenb++at++vrac.iastate.edu)
Date: 12/18/2001 12:02:31


Has this bug been resolved with the latest release of Performer for
Linux?

In other words, are the binaries in the latest release compiled with the
most recent C++ ABIs or will it still seg fault when running
applications that use dynamic_cast<>?

-Allen

Allen Bierbaum wrote:
>
> 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
> -----------------------------------------------------------------------
> 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

-- Allen Bierbaum allenb++at++vrac.iastate.edu
-- PhD Candidate txtmsg - 5152910977++at++uscc.textmsg.com
-- VR Juggler Team http://www.vrjuggler.org
-- Virtual Reality Applications Lab http://www.vrac.iastate.edu


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue Dec 18 2001 - 11:59:15 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.