blue@cam.nist.gov (Jim Blue) (02/15/90)
I just got my Personal Iris and was trying to run the examples in the Graphics Library Programming Guide. The very first example bombed with Segmentation Error. The offending line is shademodel(FLAT); If I take out this line, it works. Doing shademodel((long)FLAT); doesn't help. Does shademodel work for others?
tarolli@riva.esd.sgi.com (Gary Tarolli) (02/15/90)
In article <2548@fs1.cam.nist.gov>, blue@cam.nist.gov (Jim Blue) writes: > I just got my Personal Iris and was trying to run the examples in the > Graphics Library Programming Guide. The very first example bombed with > Segmentation Error. The offending line is > shademodel(FLAT); > If I take out this line, it works. Doing > shademodel((long)FLAT); > doesn't help. > > Does shademodel work for others? The usual explanation for this is that you called shademodel() before winopen. Only a few of the window hints are legal to call before winopen. The others require that there be a current window. From your description I cannot tell if this is what you did, but it sure sounds like it. -- Gary Tarolli
ghelms@hellfire.sgi.com (Gretchen Helms) (02/16/90)
(Jim Blue) writes: >I just got my Personal Iris and was trying to run the examples in the >Graphics Library Programming Guide. The very first example bombed with >Segmentation Error. The offending line is > shademodel(FLAT); >If I take out this line, it works. Doing > shademodel((long)FLAT); >doesn't help. If you are referring to the sample program "red.c" on page I-5 in the Introduction, that is what we refer to as a "documentation bug", and already has a bug report filed on it by myself. >Does shademodel work for others? Essentially, the call to shademodel(FLAT) MUST occur AFTER the call to winopen. If you call it BEFORE winopen, it will toss its cookies and die. I will do my best to get this fixed in the next documentation update. G. "Murdock" Helms A host is a host & from coast to coast Silicon Graphics No one will talk to a host that's close Product Support Engineer Unless the host (that isn't close) ghelms@sgi.sgi.com Is busy, hung or dead. -D. Lesher
steve@cs.UAlberta.CA (Stephen Samuel) (02/19/90)
In article <50750@sgi.sgi.com>, tarolli@riva.esd.sgi.com (Gary Tarolli) writes: > In article <2548@fs1.cam.nist.gov>, blue@cam.nist.gov (Jim Blue) writes: > > I just got my Personal Iris and was trying to run the examples in the > > Graphics Library Programming Guide. The very first example bombed with > > Segmentation Error. The offending line is > > shademodel(FLAT); > > The usual explanation for this is that you called shademodel() before winopen. > Only a few of the window hints are legal to call before winopen. The others > -- > Gary Tarolli Yep, this sounds like the right explanation, but what really bothers me is WHY CAN'T WE GET MEANINGFUL ERROR MESSAGES????? Something like 'Illegal call with no window open' would help users to solve a problem without beating their head against a wall or calling the hotline. If it's possible to identify the graphics call that's blowing up, then this helps even more. Since your documentation doesn't always clearly state what can, or cannot be called before a window open (hint, hint!), there is even more reason to encourage reasonable error messages. Stephen samuel (userzxcv@ualtamts.bitnet or alberta!obed!steve) -- Stephen samuel (userzxcv@ualtamts.bitnet or alberta!obed!steve)
tarolli@riva.esd.sgi.com (Gary Tarolli) (02/20/90)
. . . > Yep, this sounds like the right explanation, but what really bothers me is > WHY CAN'T WE GET MEANINGFUL ERROR MESSAGES????? > Something like 'Illegal call with no window open' would help users to > solve a problem without beating their head against a wall or calling the > hotline. If it's possible to identify the graphics call that's blowing > up, then this helps even more. > > Since your documentation doesn't always clearly state what can, or cannot > be called before a window open (hint, hint!), there is even more reason > to encourage reasonable error messages. > The graphics call that blew up can be identified by using dbx on the core file. A stack track should readily identify the offending routine. As for the error messages, here's the reason. Some of the GL calls, eg. v3f have to be called at a very rapid rate (> 1 million per second) to achieve the graphics performance the hardware can deliver. Putting in something as simple as an "if" test and worse yet a subroutine call (even if its not taken it will make the routine a non-leaf routine which adds lots of code to the procedure's entry and exit code), will seriously degrade performance. Although there are many routines that are not performance critical, there are also many many things to test for. The code would not be easy to implement - imagine the problem of checking for a valid pointer - you should really try to access the data while catching segv signals - but what if the user is also catching segv signals? etc etc. However, your point is valid - we need better error messages and parameter checking. Rather than add code to the GL, most of us would prefer to build an alternate GL that could be used for debugging. THus the performance of the real GL would not be affected. This debugging GL would only be used while debugging. It could be implemented as a separate library, for those who don't use the shared lib, or as a "somehow switchable" part of the shared library that could be activated when desired, or as a DGL filter. We have many options here, however I cannot promise anything soon. Make your voice heard by calling the HOTLINE and requesting 2 things: 1) a GL error message/debugging guide, preferrably 50-100 pages worth 2) a version of the GL library that does error checking as described above. -- Gary Tarolli
moss@BRL.MIL ("Gary S. Moss", VLD/VMB) (02/21/90)
[Gary Tarolli writes:] < A stack track should readily identify the offending routine. As for < the error messages, here's the reason. Some of the GL calls, eg. v3f have < to be called at a very rapid rate (> 1 million per second) to achieve the < graphics performance the hardware can deliver. Putting in something as simple < as an "if" test and worse yet a subroutine call (even if its not taken it will < make the routine a non-leaf routine which adds lots of code to the procedure's < entry and exit code), will seriously degrade performance. Although there are < many routines that are not performance critical, there are also many many < things to test for. Well, I understand that in general you don't want the overhead, but many of the one time window configuration GL calls, like shademodel() could benefit from a simple test for a NULL pointer. Even a failed assertion (using assert()) would be better than letting a segmentation violation occur. It may be that the design of the code does not permit this, but that would be a bad design. < The code would not be easy to implement - imagine the < problem of checking for a valid pointer - you should really try to access < the data while catching segv signals - but what if the user is also catching < segv signals? etc etc. Checking a pointer's validity is trivial if pointers are initialized to NULL *and* reset to NULL once invalidated by winclose() or whatever. Permitting an uninitialized variable to be used as a pointer is sloppy coding. < However, your point is valid - we need better error messages and parameter < checking. Rather than add code to the GL, most of us would prefer to build < an alternate GL that could be used for debugging. THus the performance of < the real GL would not be affected. This debugging GL would only be used < while debugging. It could be implemented as a separate library, for those < who don't use the shared lib, or as a "somehow switchable" part of the < shared library that could be activated when desired, or as a DGL filter. A method that we find useful and easy to maintain is to frame any such code segments that either impact performance or are inappropriate for production use (i.e. assert() calls) with #ifdef DEBUG ... #endif compiler directives so that a debugging version can be easily compiled and made available without having to maintain separate sources.