After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 655412 - Don't use the 'NULL' GModule to resolve GL symbols
Don't use the 'NULL' GModule to resolve GL symbols
Status: RESOLVED FIXED
Product: cogl
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Cogl maintainer(s)
Cogl maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-07-27 11:34 UTC by Neil Roberts
Modified: 2011-07-27 15:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't use the 'NULL' GModule to resolve GL symbols (18.18 KB, patch)
2011-07-27 11:34 UTC, Neil Roberts
accepted-commit_now Details | Review

Description Neil Roberts 2011-07-27 11:34:30 UTC
Cogl can sometimes accidentally resolve symbols from the wrong GL
library.
Comment 1 Neil Roberts 2011-07-27 11:34:32 UTC
Created attachment 192747 [details] [review]
Don't use the 'NULL' GModule to resolve GL symbols

Previously, _cogl_get_proc_address had a fallback to resolve the
symbol using g_module_open(NULL) to get the symbol from anywhere in
the address space. The EGL backend ends up using this on some drivers
because eglGetProcAddress isn't meant to return a pointer for core
functions. This causes problems if something in the process is linking
against a different GL library, for example Cairo may be linking
against libGL itself. In this case it may end up resolving symbols
from the GL library even if GLES is being used.

This patch removes the fallback. The EGL version now has its own
fallback instead which passes the existing libgl_module from the
renderer to g_module_symbol so that it should only get symbols from
that library or its dependency chain. The GLX and WGL winsys only call
glXGetProcAddress and wglGetProcAddress. The stub winsys does however
continue using the global symbol lookup.

The internal _cogl_get_proc_address function has been renamed to
_cogl_renderer_get_proc_address because it needs a connected renderer
to work so it could be considered to be a renderer method. The pointer
to the renderer is passed down to the winsys backends so that it can
use the data attached to the renderer to get the module pointers.
Comment 2 Neil Roberts 2011-07-27 15:24:20 UTC
Pushed as d259a87602