MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

Lionel Ulmer lionel.ulmer at free.fr
Thu Dec 23 06:53:32 CST 2004


> 1) There seems to be a bug in our msvcrt file reading APIs. I've chased
>    this one before and got nowhere, but maybe somebody more familiar with
>    the code can find it. We seem to pass back corrupt data: with builtin
>    msvcrt the demo complains with a nicely detailed assertion that it
>    can't find a file marker it's looking for. Native MSVCRT from WinXP
>    makes it work (once you set winver=winxp)

Yeah, I already tried once to debug this and was a bit stuck... I had no
idea how to progress further on this though.

> 2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's
>    showing the pre-recorded demos the sky is just fine. The rest of the
>    graphics are perfect.

Did you try with a 'reference driver' (like Mesa) ? It's pretty rare that a
bug is specifically in Wine's implementation of OpenGL but rather in
interactions between Wine and the GL driver.

And more important, it's a bitch to find out exactly which graphic
primitives are responsible to display something like the sky in thousands of
GL traces so it's almost impossible to debug.

> Finally if you put it in desktop mode, an X protocol error occurs
> initialising OpenGL. The XGetWindowAttributes call complains of a bad
> window. I debugged this for a bit and got nowhere, it wasn't as
> straightforward as it looked. Suffice to say that at the point it died
> opengl32.dll had been initialised several times already with the same
> value for root_window, and it worked each time previously (yes sync was
> enabled).

The bug was actually not that hard to find. Basically, what happens is the
following (with some additionnal TRACEing added in X11DRV):

0009:trace:x11drv:X11DRV_create_desktop created 4800007
  'Supreme.exe' starts and gets its own Desktop window
000c:trace:x11drv:X11DRV_create_desktop created 4e00007
  Now the 'graphic chooser' application starts and creates its own Desktop
  window
000c:trace:opengl:process_attach 0x78052988 04e00007
000c:trace:opengl:process_attach 0x78052988 04e00007
(...)
  In the case of the 'graphic chooser', one can see it uses the correct
  window.
0009:trace:opengl:process_attach 0x78054910 04e00007
  But then the main games does a 'LoadLibrary' on OpenGL and the
  'process_attach' function is called.

And as one can see, the Desktop window 'atom' seems to have been changed by
the 'graphic chooser' application which means that 'Supreme.exe' tries to
get the Window attributes of a window that is now deleted => nice X11 crash.

This will surely be fixed by any proper 'only one window' Desktop patches
(for which I lust for since a long time :-) )... I will see how I could
'hack' this while waiting for the proper Desktop fix (maybe having some
'process-local' atom to store the Desktop window instead of a global one).

> This seems to affect all OpenGL+desktop mode apps.

It only affects applications which do start 'helper' applications before
doing OpenGL stuff. For example, 'TreeMark' works fine in Desktop mode.

        Lionel
	
PS: are the 'TID' globally unique or are they only 'process unique' ?

-- 
		 Lionel Ulmer - http://www.bbrox.org/



More information about the wine-devel mailing list