http://bugs.winehq.org/show_bug.cgi?id=29236
Bug #: 29236 Summary: BadDrawable (invalid Pixmap or Window parameter) error running 3d apps Product: Wine Version: 1.3.34 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: rockorequin@hotmail.com Classification: Unclassified
wine-1.3.34 (but not wine-1.3.33) gives me this error in CoD Modern Warfare 1, Modern Warfare 3, and Crysis2 shortly after the initial splash screen appears:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 140 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Resource id in failed request: 0x440000f Serial number of failed request: 20 Current serial number in output stream: 21
It's a little bit tricky to bisect because it doesn't *always* happen, so I have to try, say 10 times, if the bisect seems good, but the bad commit might be in wine-1.3.33-230-g0f10ac9:
0f10ac93580d5a055f0b3f6e7c3d77738135f031 is the first bad commit commit 0f10ac93580d5a055f0b3f6e7c3d77738135f031 Author: Henri Verbeet hverbeet@codeweavers.com Date: Mon Nov 28 21:30:57 2011 +0100
ddraw: Create the wined3d swapchain when setting the cooperative level.
:040000 040000 f8a8ea10d91985680fe1e29e2fb64aaf8bc59e2d ab3f595c09537f3f18bd03bbe708c584f62e3952 M dlls
http://bugs.winehq.org/show_bug.cgi?id=29236
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |0f10ac93580d5a055f0b3f6e7c3 | |d77738135f031
http://bugs.winehq.org/show_bug.cgi?id=29236
PommeGolden lapommegolden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lapommegolden@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2011-12-07 07:25:20 CST --- This doesn't seem to be happening for me with 1.3.34 and Crysis 2. Are you sure the commit before 0f10ac93580d5a055f0b3f6e7c3d77738135f031 works correctly? Crysis 2 seems to use ddraw only for getting the amount of video memory and setting the display mode, I don't think that code should do anything particularly interesting with XShmPutImage(). Which hardware and drivers are you using? Is this a clean prefix?
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #2 from rocko rockorequin@hotmail.com 2011-12-07 08:30:53 CST --- The commit before seemed to work fine ie I was bisecting. The issue with tracking the problem exactly is that it happens pretty much every time I run it in 1.3.34, but sometimes it works in earlier versions (hence why I was trying up to 10 times).
To better test it, I tried to revert the commit where I found the problem but it failed to revert.
In each case (CoD MW1 & MW3 and Crysis2) I installed using a clean, separate prefix.
I'm using an Nvidia 540M card running via VirtualGL to Sandy Bridge graphics (I'm using ironhide). So has anything changed that might have confused VirtualGL?
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #3 from rocko rockorequin@hotmail.com 2011-12-07 08:31:43 CST --- By "but sometimes it works in earlier versions" I meant it sometimes works and then fails on subsequent tries.
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #4 from Henri Verbeet hverbeet@gmail.com 2011-12-07 08:50:51 CST --- (In reply to comment #2)
I'm using an Nvidia 540M card running via VirtualGL to Sandy Bridge graphics (I'm using ironhide). So has anything changed that might have confused VirtualGL?
I think that could be significant. I don't have that kind of hardware, so not a lot of experience with VirtualGL, but if I understand correctly it redirects some X11 / GL calls to a different GPU.
The main difference between before and after that commit is that we now initialize GL and create the corresponding window earlier for ddraw. That means that in some cases we may now have two GL contexts active at the same time while previously we didn't. That shouldn't be a problem by itself, but I suppose if something messed up X or GL synchronization you could get that kind of BadDrawable errors. I suppose it would be useful if anyone could reproduce this without VirtualGL, since we could rule that out as a factor then.
http://bugs.winehq.org/show_bug.cgi?id=29236
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #5 from rocko rockorequin@hotmail.com 2011-12-16 19:20:44 CST --- Yes, VirtualGL intercepts the OpenGL commands, sends them to the nvidia card, and sends the rendered output to the intel chipset for display.
The main difference between before and after that commit is that we now initialize GL and create the corresponding window earlier for ddraw. That means that in some cases we may now have two GL contexts active at the same time while previously we didn't.
It definitely is related to timing: I just managed to run CoD4 exactly once out of ten attempts with the latest wine-1.3.35. And both CoD8 and CoD4 always crash just after the splash screen when the game is trying to initialize its graphics screen, so it sounds plausible that two active GL contexts might be causing the crash.
What is the best debug channel to enable to see what might be going on here? And is there an easy way to delay the initialization of GL (since I can't revert that single commit)?
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #6 from Henri Verbeet hverbeet@gmail.com 2011-12-16 23:13:13 CST --- (In reply to comment #5)
What is the best debug channel to enable to see what might be going on here?
In principle +wgl should show what happens in terms of GL contexts, and it may be interesting to see if +synchronous makes any difference.
And is there an easy way to delay the initialization of GL (since I can't revert that single commit)?
Not really.
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #7 from rocko rockorequin@hotmail.com 2011-12-16 23:36:06 CST --- Created attachment 38000 --> http://bugs.winehq.org/attachment.cgi?id=38000 log of crash with +wgl enabled
Here's a log of the crash with +wgl enabled.
I tried +synchronous and it does make it less likely for the crash to occur. (But I think it also worked the first time I tried with +wgl as well - perhaps logging the debug output affects the timing by slowing things down.)
One observation that may not be related is that the window titlebar disappears when the graphic window initialises in wine 1.3.35, whereas it doesn't do this in wine-1.3.33.
http://bugs.winehq.org/show_bug.cgi?id=29236
rocko rockorequin@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38000|0 |1 is obsolete| |
--- Comment #8 from rocko rockorequin@hotmail.com 2011-12-18 08:14:54 CST --- Created attachment 38018 --> http://bugs.winehq.org/attachment.cgi?id=38018 log with +wgl +d3d
The last log showed the BadDrawable error after an X11DRV_wglDeleteContext call, but this log with +d3d as well shows there are more calls after that call. The last d3d call before the crash is:
trace:d3d:wined3d_device_set_texture Setting new texture to 0x1f7ab0.
Does a 'set texture' cause a call to X_ShmPutImage? Are there any other debug channels that might contain useful information?
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #9 from Henri Verbeet hverbeet@gmail.com 2011-12-18 09:02:13 CST --- (In reply to comment #7)
One observation that may not be related is that the window titlebar disappears when the graphic window initialises in wine 1.3.35, whereas it doesn't do this in wine-1.3.33.
Could be related to bug 29373.
(In reply to comment #8)
Does a 'set texture' cause a call to X_ShmPutImage?
No, wined3d_device_set_texture() just updates the wined3d state. The corresponding GL state changes don't happen until e.g. a draw call happens.
The resource id 0x460000f does correspond to the drawable for the GL context that was destroyed earlier. The one direct call to XShmPutImage() in Wine is at http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/dib.c#l326.... If that's the call that's failing, it should show up with +bitmap. If not, is there any chance VirtualGL uses XShmPutImage() for e.g. copying data from one GPU to the other?
Are there any other debug channels that might contain useful information?
If you can make it happen with "+seh,+tid,+synchronous,+relay,+wgl,+bitmap,+ddraw,+d3d9,+d3d,+d3d_surface,+d3d_texture" all on that may help. Chances are that that will make it so slow that it will be hard to reproduce though.
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #10 from rocko rockorequin@hotmail.com 2011-12-18 20:25:16 CST --- VGL does use XShmPutImage in its bitblitter to copy the rendered image back to X. I checked and it is after the call in VGL that the BadDrawable is happening (not wine's call to it in dib.c).
VGL does trap calls to XDestroyWindow and shuts down the corresponding bitblitter (for reference, the issue I opened at VGL is at https://sourceforge.net/tracker/?func=detail&atid=678327&aid=3461176... and there's an explanation there).
Is there any chance at all that there is a thread-sync issue in wine where the context gets destroyed but slightly later another thread tries to render to it? IIRC, in a single-GPU system, X errors like BadDrawable don't bother wine but VGL by default bombs out on them. If that's true, might the BadDrawable error be occurring in a single-GPU system in wine 1.3.34 but just not causing any problems?
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2011-12-19 03:10:06 CST --- BadDrawable errors can legitimately happen upon window destruction since it's done on a different server connection. Such errors are ignored by Wine. If VGL dies on them it's a bug in VGL, it should propagate the error.
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #12 from rocko rockorequin@hotmail.com 2011-12-19 03:18:36 CST --- Is the window actually being destroyed, though? eg in the log I posted, does the resource 0x460000f get destroyed? I can see some contexts getting destroyed, but does this affect the window - don't you have to call XDestroyWindow on it explicitly?
I think the error is actually happening independently of a call from wine - it is occurring when VGL is bitblitting the result of an OpenGL render back to the X11 window - so there is no call chain to propagate the error back along. VGL catches all the XDestroyWindow calls and stops itself writing back to the destroyed windows. I put code into VGL to confirm this, and I could see XDestroyWindow calls for other windows, but not for the resource that is causing the BadDrawable error. So shouldn't the resource still be valid? What else might cause it to be invalid??
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2011-12-19 03:29:23 CST --- You'd have to add +win,+x11drv to your trace to see what happens to the window.
Note that stopping to blit when they get XDestroyWindow isn't enough, there may be blitting calls already in the display queue. There's no way to prevent BadDrawable from happening occasionally.
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #14 from rocko rockorequin@hotmail.com 2011-12-19 04:51:07 CST --- With +win,+x11drv I can see it create three windows but only destroy two, and the third window is the one that causes the problem:
trace:x11drv:X11DRV_ExtEscape SET_DRAWABLE hdc 0x79c drawable 0 gl_drawable 0 pf 0 dc_rect (0,0)-(1594,875) drawable_rect (3,22)-(1597,897) trace:win:GetDCEx (0x40036,(nil),0x10010): returning 0x79c trace:win:GetWindowRect hwnd 0x40036 (0,0)-(1600,900) VGL: XCreateWindow created window 0x4c0000e on display 0x7dcb3b48 VGL: XCreateWindow created window 0x4c0000f on display 0x7dcb3b48 VGL: XCreateWindow created window 0x4c00010 on display 0x7dcb3b48 trace:x11drv:create_icon_window created 4c00010 ... trace:x11drv:destroy_whole_window win 0x40036 xwin 4c0000e/4c0000f VGL: XDestroyWindow called on 0x4c0000e for display 0x7dcb3b48 VGL: XDestroyWindow called on 0x4c00010 for display 0x7dcb3b48 X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
I can't see anywhere in the log where wine reports that it created 0x4c0000f, by the way, so is that one that VGL specially created?
dlls/winex11.drv/window.c#destroy_whole_window only explicitly destroys the 'whole_window', not the 'client_window':
... TRACE( "win %p xwin %lx/%lx %d)\n", data->hwnd, data->whole_window, data->client_window ); wine_tsx11_lock(); XDeleteContext( display, data->whole_window, winContext ); XDeleteContext( display, data->client_window, winContext ); if (!already_destroyed) XDestroyWindow( display, data->whole_window ); data->whole_window = data->client_window = 0; ...
Are the windows data->whole_window and data->client_window linked and does X11 know this and invalidate the third window (0x4c0000f in this case) itself? Did wine create 0x4c0000e and 0x4c0000f or did VGL create them? If wine created them, should wine explicitly destroy data->client_window as well?
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2011-12-19 05:00:55 CST --- The client window is a child of the whole window, so it's destroyed automatically by X11 when the parent is destroyed, we don't need to do it explicitly.
http://bugs.winehq.org/show_bug.cgi?id=29236
--- Comment #16 from rocko rockorequin@hotmail.com 2011-12-19 05:45:43 CST --- Thanks for the help, it turns out that VGL isn't checking for child windows on XDestroyWindow so this bug is invalid in wine. I guess it's odd that this didn't show up sooner.
Should I just mark this resolved or is there an invalid status?
http://bugs.winehq.org/show_bug.cgi?id=29236
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2011-12-19 06:09:52 CST --- Marking invalid then.
http://bugs.winehq.org/show_bug.cgi?id=29236
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Henri Verbeet hverbeet@gmail.com 2011-12-31 01:29:45 CST --- Closing.
-
wine-bugs＠winehq.org