`Renderer::glMsgCallback` crashes due `reinterpret_cast`.

Summary

Whenever Renderer::glMsgCallback is called with userParam set to a renderer will crash due to reinterpret_cast casting to BaseObject*. This would work if Renderer inherited from BaseObject, but this isn't the case. Later on, when the reinterpreted pointer is used to call a method on BaseObject this will cause a crash.

Note that this issue is exclusive to the branch graphics_api_merge (might be merged and deleted by the time you see this, dear reader).

How to reproduce ?

This will occur whenever an OpenGL call reports an error with userParam set to a renderer.

Raspberry pi 4

  1. Enable OpenGL debugging and profiling, then build splash.
cmake -DDEBUG_OPENGL=ON -DPROFILE_OPENGL=ON -B <your build folder> && make -C build -j$(nproc)
  1. Run splash with the gles renderer
./build/src/splash -r gles

The OpenGL ES spec does not require profiling calls to be supported. So whenever the pi hit a profiling call, OpenGL ES called glMsgCallback with a GL_INVALID_ENUM error.

Other platforms (desktop)

Note that this bug may not occur with some desktop drivers such as nvidia's drivers since they seem to support profiling with OpenGL ES. In that case, you can break any other call with the caveat that the userParam pointer MUST point to something that doesn't inherit from BaseObject like a renderer. This is because some classes like Window, Warp, and VirtualProbe set themselves as userParam on entering their render method, then restore the previous value (usually _root) on exit.

For example, you can go to Texture_Image::setGLTextureParameters, and instead of:

    glBindTexture(_textureType, _glTex);

do:

    glBindTexture(1337, _glTex);

Expected behavior

The application should handle OpenGL errors, and exit gracefully when a fatal error occurs instead of crashing.

What is the frequency of occurrence of this behavior ?

This bug occurs everytime you launch splash under the conditions mentioned above.

Edited by Tarek Yasser