Roderick Colenbrander wrote :
On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> 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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Roderick Colenbrander wrote:
Roderick Colenbrander wrote :
On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> 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
Roderick Colenbrander wrote:
Roderick Colenbrander wrote :
On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> 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
On Thu, Nov 02, 2006 at 02:25:33PM +0100, Roderick Colenbrander wrote:
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.
just for the files: the glGetIntegerv is also the last thing that the java stacktrace of IL2 shows up. i will try this patch against all the games, that are no longer working on my end. -- cu
On Thu, Nov 02, 2006 at 05:46:07PM +0100, Christoph Frick wrote:
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. just for the files: the glGetIntegerv is also the last thing that the java stacktrace of IL2 shows up. i will try this patch against all the games, that are no longer working on my end.
one of the patches from 2006-10-31 fixed my problems as it seems. IL2 now crashed out 1 of 4 starts but with another error. the remaining stuff is fine - although NASCAR 2003 is very slow now. -- cu
On Thu, Nov 02, 2006 at 05:46:07PM +0100, Christoph Frick wrote:
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. just for the files: the glGetIntegerv is also the last thing that the java stacktrace of IL2 shows up. i will try this patch against all the games, that are no longer working on my end.
one of the patches from 2006-10-31 fixed my problems as it seems. IL2 now crashed out 1 of 4 starts but with another error. the remaining stuff is fine - although NASCAR 2003 is very slow now.
-- cu
Regarding the slowness of nascar2003 is it caused by the recent patches a none of them have really changed the code. The patches I have sent have mainly changed the location of the code (location in opengl32.dll/gdi32.dll/winex11.drv). The only change that could have had performance implications was the pixel format of august/september. Regards, Roderick -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
On Fri, Nov 03, 2006 at 01:57:33PM +0100, Roderick Colenbrander wrote:
one of the patches from 2006-10-31 fixed my problems as it seems. IL2 now crashed out 1 of 4 starts but with another error. the remaining stuff is fine - although NASCAR 2003 is very slow now. Regarding the slowness of nascar2003 is it caused by the recent patches a none of them have really changed the code. The patches I have sent have mainly changed the location of the code (location in opengl32.dll/gdi32.dll/winex11.drv). The only change that could have had performance implications was the pixel format of august/september.
i will go and bisect for it... -- cu
Roderick Colenbrander wrote:
Roderick Colenbrander wrote :
On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> 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
Hi, I think that the patch which I just sent titled 'X11DRV: opengl init fix' should fix the issues. The patch makes sure that opengl is initialized when x11drv wgl functions are called. Regards, Roderick -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
Roderick Colenbrander wrote :
Hi,
I think that the patch which I just sent titled 'X11DRV: opengl init fix' should fix the issues. The patch makes sure that opengl is initialized when x11drv wgl functions are called.
Regards, Roderick
Your patch works OK for me. It fixes the crash when lauching WoW in OpenGL mode. Thanks, Bertrand.
I think one of the recent opengl patches breaks some games. I use the sources checked out yesterday. Here is the log of Star Wars: Knights of the Old Republic: ~/.wine/c/kotor $ wine swkotor.exe err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default context. err:module:LdrInitializeThunk "opengl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C \\kotor\\swkotor.exe" failed, status c0000142
Roderick Colenbrander wrote :
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.
I have attached the log file that you have requested. I think it makes everything clear : the cause of the failure appears at the very beginning (line 2), X11DRV_wglGetProcAddress fails to load 'wglGetIntegerv'. This error is generated by process_attach(). The log file also shows that the OpenGL initialization occurs *after* process_attach() is called. The sequence is : 1. process_attach() is called => X11DRV_wglGetProcAddress() returns NULL since OpenGL has not been initialized (error on line 2 of the log file) 2. X11DRV is initialized 3. internal_glGetIntegerv is called and fails since wine_wgl.p_wglGetIntegerv is NULL. So internal_glGetIntegerv() is called after X11DRV startup (which is the expected behaviour) but it uses a pointer that has been set *before* X11DRV startup, hence the failure. Bertrand.
participants (6)
-
Bertrand Coconnier -
Christoph Frick -
Christoph Frick -
Nick Law -
Richard Kung -
Roderick Colenbrander