[HOpenGL] Re: OpenGL/GLUT examples crashing: known problem?

Hi! I haven't received any follow-ups to this message. I realize it's a tough problem to sort out remotely. Any ideas on where I might go next? I'd like to get to the bottom of this crashing problem. How can I narrow down where the problem lies? How can I determine why an equivalent C program works, but the Haskell program crashes? Is there a way to trace just exactly what the Haskell program is doing? On 2005 Apr 10, Tim Smith wrote:

Claus, Sven & all,

On 2005 Apr 09, Claus Reinke wrote:

...

not sure whether this helps, but I just compiled and ran the redbook examples here (win98se, ghc6.4), and all but 2 looked well-behaved.

Thanks for the reply, Claus! It's good to know that the examples are working for you - I know it's something that *could* work for me.

...

As for parameters, "fgrep -w args *hs" shows that the only programs that admit to inspecting their parameters have a sensible default. More interesting are the interactions, as far as they go beyond <esc> for exit - check the keyboard functions in the sources to get an idea.

Btw, you probably shouldn't redirect the (error-)output to /dev/null if you want to know what goes wrong;-) On my ancient configuration, several examples report unknown OpenGL calls or missing extensions.

I should have mentioned; they're all dumping core, terminated with SIGBUS (except for MVArray, which requires a missing extension for me).

I ran all the failing ones under gdb, just to see if I could get any info. They failed in several different functions. Some failed in gluSphere(), like:

#0 0x281612b7 in gluSphere () from /usr/X11R6/lib/libGLU.so.1 #1 0x280ce2a2 in glutWireSphere () from /usr/X11R6/lib/libglut.so.3 #2 0x0804d47d in s4HC_info () #3 0x00000000 in ?? () #4 0x3ff00000 in ?? () #5 0x00000014 in ?? () ...

A number failed in r200UpdateMaterial, like:

#0 0x28726bad in r200UpdateMaterial () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x28728c93 in r200ValidateState () from /usr/X11R6/lib/modules/dri/r200_dri.so #2 0x28746289 in r200VtxfmtInvalidate () from /usr/X11R6/lib/modules/dri/r200_dri.so #3 0x287e648c in _tnl_wrap_filled_vertex () from /usr/X11R6/lib/modules/dri/r200_dri.so #4 0x287c452e in _mesa_init_varray () from /usr/X11R6/lib/modules/dri/r200_dri.so #5 0x281a4a86 in OpenGLSurfaceEvaluator::bgntfan () from /usr/X11R6/lib/libGLU.so.1 #6 0x281a4d0e in OpenGLSurfaceEvaluator::evalUStrip () from /usr/X11R6/lib/libGLU.so.1 ...

There were a few other failure points (glutSolidCube, glutVideoPan).

Taking the second one, from BezMesh.hs, I comment out the initlights call in the myInit function. Then the program runs to completion, and displays the mesh as a silhouette.

Or, if I leave initlights in, but comment out the evalMesh2 call, then it works OK (but just displays a black window).

I tried the C versions from here:

http://www.opengl.org/resources/code/basics/redbook/

And compile them like this:

cc -g -Wall -W -I/usr/X11R6/include -L/usr/X11R6/lib bezmesh.c \ -lglut -lGL -lGLU -lX11 -lm -o bezmesh

Those C examples all work fine, except for aaindex and fogindex which can't find the visual needed - no core dumps.

Unfortunately, I'm not sure where to start looking for the source of this problem. Even if no one else has seen something like this, maybe there is some good method of tracking down what part is broken?

I'm using the OpenGL implementation that comes with X.org version 6.8.1 under FreeBSD 5-STABLE, and the libglut-6.0.1 port.

Thanks, Tim -- If you're not part of the solution, you're part of the precipitate.