Ian,

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:

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.
  
Are you saying that if I didn't check explicitly for GL_ARB_vertex_buffer_object i.e. (in glew)
glewIsSupported("GL_ARB_vertex_buffer_object")
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 a question.

or - the other possibility - I definitely have to call
glewIsSupported("GL_VERSION_1_5")

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.

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
happening.
  
Well - the invalid context is ruled out. See my previous post. The context is certainly valid.
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, so
yum install toped
should be enough.
Is that possible?

Regards
Svilen