#174 glGetString( GL_EXTENSIONS ) is no more valid since opengl 3

API (59)

As this is the process to query extension in glew.c it does not work with an opengl 3 core/forward context.
glGetStringi must be used

See attached glew.c modified from 1.6.0


1 2 > >> (Page 1 of 2)
  • MatRem

    MatRem - 2011-09-01
  • Nigel Stewart

    Nigel Stewart - 2011-09-01

    Duplicate of Bug 2927731: Calling glGetString(GL_EXTENSION) even in Core/FC context

  • Nigel Stewart

    Nigel Stewart - 2012-09-18
    • status: pending --> closed
    • assigned_to: Nigel Stewart
    • milestone: --> 1.9.0
  • Nigel Stewart

    Nigel Stewart - 2012-09-18

    Closing as duplicate.

    • status: closed --> open
    • milestone: 1.9.0 --> 1.9.1
  • Nigel Stewart

    Nigel Stewart - 2012-09-18

    Re-opening, since there is a patch attached.
    Will consider for GLEW 1.9.1.

  • Nigel Stewart

    Nigel Stewart - 2012-11-12
    • milestone: 1.9.1 --> 1.9.2
  • Carsten Neumann

    Carsten Neumann - 2013-03-14

    I'm attaching a patch against 41c1305a, that adjusts how glew.c is generated so that it does the right thing depending on the GL_VERSION reported by the context.
    One side effect is that glewGetExtension() makes a lot more GL calls (it iterates through all extension, calling glGetStringi for each, until it finds the one it is looking for).
    Tested on Fedora 17 x86_64, glewinfo output is unchanged before/after the patch.

  • Nigel Stewart

    Nigel Stewart - 2013-03-19
    • milestone: 1.9.2 --> 1.9.1
    • priority: 5 --> 2
  • Nigel Stewart

    Nigel Stewart - 2013-03-19

    Thanks for the patch! Appreciated.

  • Nigel Stewart

    Nigel Stewart - 2013-07-13
    • status: open --> pending
  • Nigel Stewart

    Nigel Stewart - 2013-07-13

    Patch applied to git TOT.
    GLEW 1.10.0 coming soon.
    Thanks for the patch!

    • Nigel
  • Nigel Stewart

    Nigel Stewart - 2013-07-22
    • status: pending --> accepted
    • Group: 1.9.1 --> 1.9.2
    • Priority: 2 --> 1
  • Nigel Stewart

    Nigel Stewart - 2013-07-22

    I observed issues on Windows with this patch, and reverted it at the last moment for the purpose of GLEW 1.10.0. (Argh!) Bumping this to the "1.9.2" category for a GLEW 1.10.1.

    • Nigel
  • Anonymous - 2013-07-22

    Can you post details about the issues? I may be able to take a look (no promises I'm afraid) later this week.

  • Nigel Stewart

    Nigel Stewart - 2013-07-22

    In a nushell - glGetStringi hasn't been loaded yet when we're in the process of looking at all the extensions, before we go ahead and init based on the version and extensions. On Windows GLEW seemed to be trying to link glGetStringi from opengl32.dll - a deal breaker.

    • Nigel
  • Carsten Neumann

    Carsten Neumann - 2013-07-22

    Hmm, weird, the split of glew_init_gl.c into two parts was supposed to avoid that, guess I missed a spot - I'll see if I can find it.

  • Nigel Stewart

    Nigel Stewart - 2013-08-23

    I'm thinking of revisiting this in September for the purpose of a 1.10 bugfix release. If you can spare any cycles, I'd like to put this one to rest.

  • Nuwen

    Nuwen - 2013-08-26

    How about the attached minimally invasive patch? (This is against 1.10.0's generated glew.c, since I'm on Windows and I haven't tried to regenerate glew, but it should be trivial to apply to the master sources.)

    Basically, there are only two calls (as far as I can see) to glGetString(GL_EXTENSIONS). This replaces them with calls to _glewGetExtensions(), a static helper function. This manually attempts to retrieve glGetStringi(), therefore it should not interfere with the "normal" retrieval and it should not be sensitive to when it is run during the glew initialization process. If it can retrieve glGetStringi(), it concatenates each extension into a static array, space-separated, and returns a pointer to that array. This avoids any CRT dependencies. If glGetStringi() returns a null pointer, the whole function returns null (as the callsites check for).

    On the other hand, if glGetStringi() cannot be retrieved, the helper falls back to the deprecated call to glGetString(GL_EXTENSIONS).

    On my machine, this returns identical strings (including the final space) for both the new-style and old-style codepaths for the compatibility profile (only the new-style works for core, of course, and it is the same except it lacks GL_ARB_compatibility), so the rest of glew should be oblivious as to which path was taken.

    The only squirrelly bit is choosing the size of the static array. My machine (GTX 680, latest drivers) returns a string about 7000 chars long, so I chose 16 KB - this is hopefully plenty for all machines but not unnecessarily bloated.

    • Anonymous - 2015-02-04

      Just tried the patch from Nuwen and it seems to work well. Not sure why this problem has required 5 years of deliberation without any official action.

  • Carsten Neumann

    Carsten Neumann - 2013-09-13

    Sorry for the delay. I'm not able to reproduce the problem (or I just don't understand it properly - I don't develop a lot under windows): I've copied the generated glew.{c,h}, glewinfo.c sources to a windows machine and built glew (shared/static), glewinfo using the vc10 project there. It compiles and links without problem. I've then run glewinfo under apitrace (trace attached) and verified it only makes calls to glGetStringi - I'm attaching the trace file.
    Could you give me some additional hints on how to reproduce the problem? Thanks!

  • Anonymous - 2013-10-13

    I had an issue related to this bug (with an OpenGL 4.4 context):

    The GL_EXTENSIONS causes an GL_INVALID_ENUM which is not handled by GLEW. Instead, I caught it at a different point in my code where I checked for a previous GL function's success. So independent of this error, it would be a good idea that GLEW clears all errors it may have produced by calling glGetError() once after initialization.

    Thank you.

  • Nigel Stewart

    Nigel Stewart - 2014-07-13
    • Group: 10.10.1 --> 1.11.0
  • Anonymous - 2014-07-23

    This bug is 3 years old and now causing serious problems on OS X :( Why the push out to 1.11.0? I'm going to take a look at it.

  • Anonymous - 2014-07-28

    I am also very confused why this hasn't been fixed yet.

  • Nigel Stewart

    Nigel Stewart - 2014-08-12
    • Group: 1.11.0 --> Future
1 2 > >> (Page 1 of 2)

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

Sign up for the SourceForge newsletter:

No, thanks