Thanks again. It seems that we agree on the initialization sequence,
but there are still some details - see below.
On 12/04/2009 10:07 PM, Ian Romanick wrote:
Are you saying that if I didn't check explicitly for GL_ARB_vertex_buffer_object i.e. (in
2. You call glXGetProcedureAddress to get the valid existing entry
points to the openGL procedures for the context you obtained in p.1
glXGetProcAddress is called to get entry points. The entry points may
not be valid. Calling 'glXGetProcAddress("Hello, world!")' will return
an entry point, but it will not be valid. To know which entry points
are valid, you have to check the GL version (by calling
glGetString(GL_VERSION)) and / or the GL extension string (by calling
glGetString(GL_EXTENSIONS)). GLEW does the glXGetProcAddress for you.
GLEW also checks the version and the extension string and uses these to
set variables (i.e., GLEW_ARB_vertex_buffer_object) that can be tested.
then calling glGenBuffersARB is likely to crash provided that it is
there? I'm not arguing that this is a good coding practice - it's just
or - the other possibility - I definitely have to call
before using glGenBuffers()
? Even if driver supports GL version (say) 2.0?
Again - I'm not arguing that this is the way it should be coded. I'm
just trying to clarify why in this particular case it is crashing and
does it have something to do with the driver.
My impression was that all this stuff is done during glewInit() and
glewIsSupported is there to help you making you code portable.
Well - the invalid context is ruled out. See my previous post. The
context is certainly valid.
That glGenBuffersARB and glGenBuffers are the same is an artifact of how
Mesa (and many GL implementations) implement them. To be clear: I
don't think this application should crash when calling glGenBuffers on
this driver. I think something else (possibly an invalid context) is
The question then remains - why the call to glGenBuffers is
dereferenced as a NULL pointer?
I'm working on a fix and will take into account your tips and
suggestions, but the impression is that in spite of all that and with
perfect diagnostic code (using glew) - it will crash again on this
particular platform. And it will be certainly embarrassing.
I think the best thing to do is to run the application on your platform
(whoever maintains the driver). I believe the hardware is available
provided that you're maintaining its driver. Then the crash can be
recreated. It's easy to install Toped - it is in Fedora repositories,
yum install toped
should be enough.
Is that possible?