Aric Cyr <Aric.Cyr <at> gmail.com> writes: > > Raphael <fenix <at> club-internet.fr> writes: > > > > > On Wednesday 14 December 2005 04:53, Aric Cyr wrote: > > > 1) should the thunks returned from wglGetProcAddress be causing crashes at > > > all? Note that they don't crash right away, but "eventually" usually > > > during > > > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). > > > > The real problem here is "why it crash ?" > > It shouldn't as wine gl* calls are only "decorators" calls > > Maybe we have a declaration error... > > Yes that was what I was thinking as well. I haven't looked into it very much > yet, but I'll double check the definitions, although since opengl_ext.c is > autogenerated I can't imagine why there would be a problem (unless > include/wine/wined3d_gl.h has the wrong definitions... I'll have to check that > out) > > Also I'm not sure if calling conventions matter, or what is the correct way to > define a function. I'm referring to the WINAPI vs APIENTRY (vs stdcall?) > function pointer prefixes. Any pointers (no pun intended) in this area would > be much appreciated. > > > Can you provide more informations: > > - WINEDEBUG=+opengl log + winedbg crash log
I debugged it more last night and I found the offending call. If I comment out just that one (probably unneeded from what I can tell) function everything works great. The code is in dlls/wined3d/drawprim.c (about halfway down): if (GL_SUPPORT(EXT_SECONDARY_COLOR)) { glDisableClientState(GL_SECONDARY_COLOR_ARRAY_EXT); checkGLcall("glDisableClientState(GL_SECONDARY_COLOR_ARRAY_EXT)"); GL_EXTCALL(glSecondaryColor3fEXT)(0, 0, 0); checkGLcall("glSecondaryColor3fEXT(0, 0, 0)"); } else { /* Missing specular color is not critical, no warnings */ VTRACE(("Specular colour is not supported in this GL implementation\n")); } If I comment out the GL_EXTCALL(glSecondaryColor3fEXT)(0,0,0); line everything works perfectly (well, the four dx9 demos I have been using). I tried debugging it (put a breakpoint in wine_glSecondaryColor3fEXT) but the function seems to work fine. It is only after this function is called, followed shortly by glDrawArrays() that the actual segfault occurs (inside glDrawArrays there is a NULL dereference it seems). I would blame ATI's drivers but as I said using glXGetProcAddress instead of wglGetProcAddress works without commenting this line. The only other thing I can think of is that the calling conventions are messed up somehow, either due to mismatched function declarations (which I thoroughly checked, but still could have missed something...) or some weird wine thing I don't understand. Also other GL_EXTCALL functions were not affected. For example, glPointParameter...EXT() calls are frequently made and don't seem to cause any problems at all. Any help or tips would be much appreciated, as I am running out of things to try and debug. - Aric