Crashing the window mgr from GL programs

[Kurt Akeley]

In article <1990Aug3.075057.11705 at cs.umn.edu>,
slevy at poincare.geom.umn.edu (Stuart Levy) writes:
|> We use a locally-written 3-d object viewer on our Irises (personal and GTX).
|> For some aberrant objects, or possibly some xform matrices pushed on
the stack,
|> we find it causes the window server to crash -- with messages resembling
|> "timeout: graphics FIFO still > 1/2 full" and/or "window server killed with
|> signal 15".  In extreme cases it can cause our GTX Iris to lock up such that
|> we must reboot to recover the graphic display, though normally we're just
|> kicked back to a login: prompt.
|> 
|> Does anyone know what kinds of geometric data can wedge the graphics
subsystem
|> this way?  If we knew what to avoid we might be able to change our
application
|> to prevent crashes.
|> 
|> 	Stuart Levy, Geometry Group, University of Minnesota
|> 	slevy at geom.umn.edu

as you suggest, there may be some geometric data or transformation that
causes the pipe to lock up.  in my experience, however, it is more likely
that you are calling GL routines in an order that is not supported, with
the same result.  a common mistake is to include GL commands other than
c(), color(), cpack(), lmbind(), lmcolor(), lmdef(), n(), RGBcolor(), t(),
or v() between bgnpolygon() and endpolygon() calls (ditto for points, lines,
closedlines, tmeshes, and qstrips).  you might expect, for example, to be
able to change the depthcue parameters within a line or polygon - sorry,
not allowed (a new GL depthcue feature will correct this and other issues
regarding the current depthcue).

of course the sequence theory makes more sense if the failure is associated
with a viewing mode, rather than with particular data sets.  if failures
can be isolated to a subset of the viewing modes, it might be worthwhile to
review the related code for unsupported GL sequences.

-- kurt