<div id="AOLMsgPart_0_cb417418-e1e3-47ce-b174-670e65718897" style="margin: 0px; font-family: Tahoma,Verdana,Arial,Sans-Serif; font-size: 12px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><font face="Arial, Helvetica, sans-serif">While looking at bug 13335 ( </font>http://bugs.winehq.org/show_bug.cgi?id=13335<font face="Arial, Helvetica, sans-serif">) which is An ATI and wine bug.<br>
I noticed something in one of the updates :<br>
</font><pre class="bz_comment_text" id="comment_text_70"><font face="Arial, Helvetica, sans-serif"><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462715">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462715</a><br>
</font><font face="Arial, Helvetica, sans-serif"><br>
Now this set me to searching as I really didn't like the idea of wrapping the libGL calls with 'winmemory' allocations<br>
(To many areas of corruption possibilities and just isn't an ellegant solution). The Debian post above points out something<br>
very interesting :<br>
<br>
" </font>After more investigation, I was able to trace this to a bug in my OpenGL <br>
initialization logic.<br>
<br>
The following (psuedocode) sequence, forces fglrx to revert to indirect <br>
rendering:<br>
dpy = XOpenDisplay()<br>
visual = glXChooseVisual(dpy)<br>
XCloseDisplay(dpy)<br>
..<br>
dpy2 = XOpenDisplay()<br>
ctx = glXCreateContext(dpy2, visual) <-- fglrx reverts to indirect <br>
rendering<br>
..<br>
<br>
Changing the code to use the same display connection for glXChooseVisual <br>
and glXCreateContext solves this problem.<font face="Arial, Helvetica, sans-serif">"<br>
<br>
So looking at that I began to Grep the latest git tree to find out where <br>
XOpenDisplay<br>
glxChooseVisual<br>
glxCreateContext<br>
XCloseDisplay<br>
<br>
are used. There are only 2 places (and yes I know they are critical places) where they are used.<br>
opengl.c and x11drv_attach.c both in the winex11.drv directory. So I went through and started looking<br>
at how they were called and discovered that the display variable (dpy and dpy2 in the above pseudocode) is not <br>
reused at all. It is allocated off the local stack of the subroutine it is in. later on gdi_display which is the global<br>
variable gets assigned display which calls the XOpenDisplay. This gdi_display is used as the global handle <br>
if I am reading the code correctly. <br>
<br>
Now this is where my pointer knowledge goes south and I think this is right... and this is where the problem might be:<br>
<br>
in the process_attach routine someone says gdi_display = display. Display is a local pointer to the routine and will<br>
go away when the function returns. <br>
<br>
Here is my theory :<br>
<br>
with the ATI card being a pig for memory and Wine allocating alot of memory itself the pointer to the driver gets invalidated<br>
somehow corrupted etc. and when it is used later X thinks its another display and everything happily crashes.<br>
<br>
Mind you this is a theory right now but is this possible? I think an easy fix to this would be to do the following instead:<br>
<br>
gdi_display = XopenDisplay()'; This allocates the display structure off the global heap not the local heap<br>
display = gdi_display;<br>
<br>
and then leave the rest of the code alone.<br>
<br>
Am I going down the right track with this? If so it would be alot simpler fix that some of the ones out there being forced around. And it should not<br>
effect any of the other supported cards.<br>
<br>
Chris<br>
</font></pre><br>
<font face="Arial, Helvetica, sans-serif"><br>
</font></div>
<!-- end of AOLMsgPart_0_cb417418-e1e3-47ce-b174-670e65718897 -->
<div id='u8CAC09AB81F2976-DD8-E10' class='aol_ad_footer'><FONT style="color: black; font: normal 10pt ARIAL, SAN-SERIF;"><HR style="MARGIN-TOP: 10px">The Famous, the Infamous, the Lame - in your browser. <A title="http://toolbar.aol.com/tmz/download.html?NCID=aolcmp00050000000014" href="http://toolbar.aol.com/tmz/download.html?NCID=aolcmp00050000000014" target="_blank">Get the TMZ Toolbar Now</A>!</FONT> </div>