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.