Bug#134262: We see segfaults from dynamic_cast only when linked to glut
We're seeing a very similar problem, but have isolated it a lot. In particular, we get a segmentation fault (or sometimes an illegal instruction) only if we are dynamically linking to glut and compiling our code with g++-3.0. If we statically link, it works. If we link to other libraries, including pthread, dl, X11 and GL, it works. If we compile with g++-2.95, it works. In addition, we can reproduce the bug with a trivial program which doesn't actual use anything from the glut library (or much of anything, really.)
Our program is:
------------------- example.cpp --------------------
class Base {
public:
virtual void go() { }
};
class Derived : public Base { };
void
bad1(void) {
Base base;
Base *base_p = &base;
(void) dynamic_cast<Derived*>(base_p); // illegal instruction or segfault
}
void
bad2(void) {
Derived derived;
Base *derived_p = &derived;
(void) dynamic_cast<Derived*>(derived_p); // illegal instr or segfault
}
int main(int, char **) {
bad1();
bad2();
return 0;
}
--------------------------------------------------
Either function fails in the dynamic cast.
Our Makefile, showing when things work and when they fail is:
------------------- Makefile --------------------
LD := g++-3.0
CFLAGS := -Wall
all:
g++-3.0 $(CFLAGS) -c example.cpp
g++ $(CFLAGS) -o example-295.o -c example.cpp
$(LD) -o badness example.o -lglut
$(LD) -o good-noglut example.o
$(LD) -o good-static example.o -static -lglut
$(LD) -o good-libs example.o -L /usr/X11R6/lib -lpthread -lX11 -lGL -ldl
$(LD) -o good-295 example-295.o -lglut
./good-noglut
./good-static
./good-libs
./good-295
./badness
--------------------------------------------------
The good-* programs work fine, but badness segfaults.
I'm running debian unstable with the following versions of things:
linux 2.4.3
gcc 3.0.4-1
libstdc++3 3.0.4.1
g++ 2.95.4-11
libstdc++2.10 2.95.2-14
libstdc++2.10-glibc2.2 2.95.4-2
glutg3 3.7-12
It may just be something odd about the glut code that is triggering this, although it seems like that shouldn't affect code which isn't calling glut functions.
Marc Shapiro mds@lions.med.jhu.edu
Dave Barnett dave@lions.med.jhu.edu
Reply to: