[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: