GNOME Bugzilla – Bug 655510
Access Violation (a.k.a Segfault) in cogl/driver/gl/cogl-gl.c
Last modified: 2011-08-01 13:15:16 UTC
Hi, I'm here to report another crasher in COGL... (this is from the msvc-branch, which follows the master branch as close as possible, to attempt to add MSVC support for compiling COGL) When I run any example program (hello, crate) that was built with COGL, all programs would crash with an access violation (0x00000005c, Segfault for Unix people). As I checked in the debugger, it seems to me that the crash occurs in the line that goes like the following (this occurs for both 32-bit and x64): --------------snippet from cogl/driver/gl/cogl-gl.c static gboolean _cogl_get_gl_version (int *major_out, int *minor_out) { const char *version_string, *major_end, *minor_end; int major = 0, minor = 0; _COGL_GET_CONTEXT (ctx, FALSE); /* Get the OpenGL version number */ /* --> the following line is the line where the COGL program crashes */ if ((version_string = (const char *) ctx->glGetString (GL_VERSION)) == NULL) return FALSE; --------------snippet from cogl/driver/gl/cogl-gl.c Upon a bit of further investigation, it seems that ctx->glGetString is NULL (0x00000000), so it may mean that some init sequence for ctx was missed for the WGL backend, or something like that. As far as I could recall, this did not occur before I merged the changes in master into the msvc-support branch since commit a9184d5cb721bb2991c26e2ec3e0e1126eb5121a ("Export API for uploading a tex subregion from a CoglBuffer"), and (maybe I am wrong) I am suspecting something was missed in the commit d259a87602516f6882138e6bc031d0647cb15140 ("Don't use the 'NULL' GModule to resolve GL symbols") that may have led to this. Note that the above-mentioned example programs ran fine on Linux with the same codebase (sorry I can't check this situation with a "normal" MSYS build as the latest unstable GLib cannot be built on Windows with MSYS). Thank you for your time! God Bless.
Hi, Upon further investigation via the VS debugger, it seems like something went wrong when the following section of code is called static CoglFuncPtr _cogl_winsys_renderer_get_proc_address (CoglRenderer *renderer, const char *name) { return (CoglFuncPtr) wglGetProcAddress ((LPCSTR) name); } in cogl/winsys/cogl-winsys-wgl.c, as the function pointer for the glGetString() function from WGL could not be acquired, causing the glGetString to be set as NULL (0x00000000) as this following section of code was being called in cogl/driver/gl/cogl-gl.c: gboolean _cogl_gl_update_features (CoglContext *context, GError **error) { ---snippet--- /* We have to special case getting the pointer to the glGetString function because we need to use it to determine what functions we can expect */ context->glGetString = (void *) _cogl_renderer_get_proc_address (context->display->renderer, "glGetString"); ---snippet--- Thank you, and God Bless!
Created attachment 192883 [details] [review] cogl-winsys-wgl: Add a fallback for failed wglGetProcAddress It looks like wglGetProcAddress is only meant to be used for extension functions (ie, not those in the core GL 1.1 API). I only tested the WGL backend using Wine which seems to let you get away with this. Here's a patch to add a fallback using GModule in a similar way to the EGL backend. It would be great if you could test this and report back. Thanks.
Hi Neil, Thanks for the work-it seems that update remedied the problems here.
Pushed as 38deb97478ace8a3fa19fe55f0a987a2ad6599d0. Thanks.