> Roderick Colenbrander wrote: > >> Roderick Colenbrander wrote : > >> > >>>> On 11/1/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> The last release of Wine 0.9.24 contains an error in the code of > >>>>> > >>>> opengl32.dll.so > >>>> > >>>>> under X11 : Wine tries to get the address of "wglGetIntegerv" (line > >>>>> > >> 608 > >> > >>>> of > >>>> > >>>>> dlls/opengl32/wgl.c) before the extensions of WGL have actually been > >>>>> > >>>> loaded > >>>> > >>>>> (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading > of > >>>>> > >>>> the > >>>> > >>>>> wglGetIntegerv address fails and afterwards, whenever > >>>>> > >>>> internal_glGetIntegerv() > >>>> > >>>>> is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception > is > >>>>> > >>>> raised. > >>>> > >>>> > >>>> This is probably already fixed in the git tree. See the commit: > >>>> winex11.drv: Fixed the prototype of many OpenGL functions. > >>>> > >>>> Jesse > >>>> > >>> Else if the problem still happens something strange is going as the > >>> > >> extensions are registered at x11drv startup. > >> > >>> Roderick > >>> > >> Yes, the problem still happens because the function process_attach() > (line > >> 582 > >> of dlls/opengl32/wgl.c) is called before the x11drv startup. The > comment > >> of > >> process_attach is very clear : "/* This is for brain-dead applications > >> that use > >> OpenGL functions before even creating a rendering context.... */". It > is > >> clear > >> that process_attach is a workaround for *brain-dead* apps :) and among > >> other > >> things it gets the address of wglGetIntegerv. This operation used to > >> succeed as > >> long as GetProcAddress() was used but now since x11drv is needed to > upload > >> the > >> wglGetIntegerv address there is some kind of race condition and the > >> operation > >> fails hence the bug. > >> > >> Bertrand. > >> > > > > Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it > was directly loaded using GetProcAddress from winex11.drv now it is still > loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine > startup (I'm not sure at which stage but I believe directly when you use > gdi stuff or perhaps even earlier) winex11.drv is initialized and during > this initialization my opengl code is initialized aswell. I wonder what causes > the race as I haven't seen it happening for other users yet. I want to > avoid a patch like yours as I plan to do similar things for some other > functions. > > > > Perhaps something goes wrong in wglGetProcAddress itself. Try running > wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is > correct you'll see some opengl information (gl version, loading of extensions) > before stuff happens in opengl32.dll. > > > > Roderick > > > Hi Roderick, do you have a patch for this problem, since 0.23 a number > of wow users seem to be getting a crash at startup that didn't happen > before 0.23 or 0.22, can't remember which, only some users not all. > > I just wondered if this is the fix for it, if we could try it out ? > > Regards > Nick
Hmm, if that is indeed the case this patch could work for them. The whole issue is new for me, I'll see what I can do about it. Right now there's some GLX code in opengl32 which creates an opengl context. I was planning to replace it with WGL code, that might help too (if I load the function pointers afterwards). Perhaps Alexandre has an idea how to correctly fight the race condition. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
