From: Markus von der Heyde (MvdH++at++Kyb.Tuebingen.MPG.de)
Date: 06/22/2001 00:42:02
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
This archive was generated by hypermail 2b29 : Fri Jun 22 2001 - 00:39:15 PDT