[osg-users] GL Error vulnerability in OSG 3.4.0 (invalid enum)

Robert Osfield robert.osfield at gmail.com
Tue Jul 19 08:49:54 PDT 2016


HI Rick,

On 19 July 2016 at 16:33, Rick Irons <Rick.Irons at mathworks.com> wrote:

> Hi Robert,
>
>
>
> Sorry for the delay in responding.  Thanks for the info below.
>
>
>
> I will investigate if the GL_MAX_3D_TEXTURE_SIZE and
> GL_MAX_ARRAY_TEXTURE_LAYERS_EXT enumerations have GLES counterparts that
> need to be considered.
>
>
>
> In regards to the fallback, wouldn’t the existing initialization of the
> two values to zero be sufficient?
>

If the driver/hardware doesn't support the actual feature that these
settings are related to then the actual values above won't ever be needed
so the value of 0 should be just fine, any value in theory would not affect
the outcome of the application.

As a general principle setting the values to 0 is probably a pretty decent
fallback as users doing debugging would be able to spot this value and
hopefully trace it back.



>  We encountered this issue of unexpected GL errors in some tests that
> exercise Microsoft’s OpenGL 1.1 software implementation.  We use this
> version of OpenGL as a fallback when issues with hardware graphics OpenGL
> are encountered.
>

It's a wonder anything works with MS's OpenGL implementation....  they've
done almost all they could have done to sabotage OpenGL over the years.

For the OSG we just need to provide more elegant fallbacks, things
shouldn't crash.  So for this particular case GL type and a version check
would be appropriate.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160719/2df0e1e4/attachment-0002.htm>


More information about the osg-users mailing list