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

[Tim Smith]

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 <tim at desert.net> wrote:
> Claus, Sven & all,
> 
> On 2005 Apr 09, Claus Reinke <claus.reinke at talk21.com> 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.