Re: OpenGL/GLUT examples crashing: known problem?

Tim Smith <[email protected]>
Newsgroups gmane.comp.lang.haskell.hopengl
Message-ID <[email protected]>
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 <[email protected]> wrote:
> Claus, Sven & all,
> 
> On 2005 Apr 09, Claus Reinke <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.