#144 GLEW check for extensions fails


I'm using GLEW 1.5.2 on Kubuntu 10.04 x64 with latest ATI 4870 10.8 proprietary drivers (fglrx).

GLEW_ARB_map_buffer_range returns false even though I know the extension is available. glxinfo reports it as available.
glewIsSupported("GL_ARB_map_buffer_range") returns false.

But glXGetProcAddress((const GLubyte *)"glMapBufferRange") returns a valid pointer.


  • Nigel Stewart

    Nigel Stewart - 2010-09-06

    Please try current release of GLEW (1.5.5) or encourage an Ubuntu/Kubuntu packager to backport for 10.4.

    If you can confirm this bug for GLEW 1.5.5, we'll take action for sure. But most likely it is already fixed.

  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • Roderick Colenbrander

    This bug is still around in GLEW and you can encounter it in many more cases. The problem is that GLEW assumes that glXGetProcAddress returns NULL when a function isn't around, but in GLX the return value of glXGetProcAddress is undefined (on WGL and others it is NULL). There was some reasoning behind it. Anyway the function loading code in Mesa behaves like this. Just try loading ' glFooBar',

    The only real way is for GLEW to check whether an extension is around before allowing to load the function.

  • Nigel Stewart

    Nigel Stewart - 2011-07-07

    Re-opening this bug.

    the return value of glXGetProcAddress is undefined

    Oh? The documentation says otherwise:

    "A NULL pointer is returned if function requested is not suported in the implementation being queried."


    There was some reasoning behind it.

    Interested to know more about that.

    • Nigel
  • Nigel Stewart

    Nigel Stewart - 2011-07-07


    The spec language:

    A return value of NULL indicates that the specified function does not exist for the implementation.

    A non-NULL return value for glXGetProcAddress does not guarantee that an extension function is actually supported at runtime. The client must also query glGetString(GL EXTENSIONS) or glXQueryExtensionsString to determine if an extension is supported by a particular context.

  • Nobody/Anonymous

    Years ago I encountered the same issue when people reported some Wine GL bugs to me. At that time I looked at in detail including at Mesa. The main reason for this behavior has to do with indirect rendering. In that case the client library submits a command buffer to the X-server and the X-server takes care of the rendering. The X-server may only support a subset of what the client library offers, so for that reason you can't rely on the return value.

    In case of Mesa, the issue there was something in their function dispatching code. I think it allowed calls to be registered after doing the GetProcAddress, but I don't fully remember.

    The issue I had in Wine is that I had to emulate wglGetProcAddress through glXGetProcAddress. Since wglGetProcAddress does return NULL, I had to make sure the extension required by the call was around or that the correct GL version was matched (in case a non-EXT / non-ARB call got loaded).

  • Nigel Stewart

    Nigel Stewart - 2011-08-02

    GLEW does check for the extension string before doing glXGetProcAddress: (Unless glewExperimental is true)

    Closing this again based on the discussion.

    CONST_CAST(GLEW_ARB_map_buffer_range) = _glewSearchExtension("GL_ARB_map_buffer_range", extStart, extEnd);
    if (glewExperimental || GLEW_ARB_map_buffer_range) CONST_CAST(GLEW_ARB_map_buffer_range) = !_glewInit_GL_ARB_map_buffer_range(GLEW_CONTEXT_ARG_VAR_INIT);

  • Nigel Stewart

    Nigel Stewart - 2012-09-18

    Closing. (again)

  • Nigel Stewart

    Nigel Stewart - 2012-09-18
    • status: pending --> wont-fix
    • milestone: --> 1.9.0

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks